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3,0 INTERNAL STRUCTURE, PHILOSOPHY, AND FLOW OF CONTROL. 



3.1 Introduction 

In this Section we wHl present the internal operations of the RSX-il^ 
Executive and the routines associated with It (drivers, and common 
service subroutines). Our exposition will have a tutorial slant. 
Section 5,0 contains a detailed description of the RSX-llM data 
structures. In this section we will Introduce data structures on an 
as-needed basis, and discuss the detalleo contents of these structures 
only where needed to render our exposition meaningful. 



3,2 Interrupt Mechanisms 

RSX-UM Is a priority driven, multiprogramming, real-time operating 
system, and, as with any such system. Its principal function Is the 
multiplexing of shareble resources among competing tasks. The 
multiplexing Itself Is made possible bv the Interrupt system of the 
hardware which causes control to be taken away from user tasks and 
given to the Executive, It Is during this period of Interrupt control 
+hat the Executive makes Its decisions on granting use of shared 
resources. Understanding the Interrupt mechanism Is fundamental to 
understanding the Executive, and once understood, serves as a 
framework for describing the operation of Executive subsystems 
(drivers, loader, MCR, etc) and the system as a whole. 



3,2,1 Hardware Interrupt Mechanisms - Review 9. Overview 

The PDP-11 family of computers has two classes of Inte^ruptsi 

1, Processor Traps, and 

2, External Interrupts, 

Processor traps are not maskable*, that 1s# when they occur the 

processor enters the trap sequence of pushing PS and PC onto the 

current stack, retrieving PS and PC from the orooer hardware trap 
vector^ and# If no other Interrupts are pending. Initiating the 

processor at the location specified by the trap vector, A table of 

trap vectors start at location ^ and extend to location 77^(8), 
Processor traps Include**! 



Maskable meant that the condition can be disabled by altering the 
priority of the processor, 

** See the PDP-U Processor Handbook for a complete list. 
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BPT Instruction? 
EMT Instpuctioni 
lOT Instruction? 
TRAP Instruction? 

Il/a0 Floating Point Exceotlon Fault? 

Odd address? 

Power Fall > and 

1 1 1 ega 1 Inst rue 1 1 ons. 



External Interrupts are Hardwired to one of the four bus reauest 
levels of the processor. These Interrupts are generally associated 
with I/O devices and are maskable. They can only cause an Interrupt 
when the priority In the Processor Status Word (PS) Is less than the 
priority of the Interrupting source, Thus# by setting the processor 
priority in a trap vector PS word to an appropriate level Interrupts 
equal to» or below that priority are locked out, 

&vary device (Interrupt source) has an associated trap vector 1" the 
vector table located In lower fnemory. 

With this sketch of the hardware mechan1sw# we can examine the 
Interrupt processing In the Executive Itself, 



3,2*2 Executive Interrupt Processing 

Let us assume that all the vectors In the trap' vector table have been 
properly Initlallfed so that when a processor trap or Interrupt 
occursi an Executive routine will obtain control of the processor*. 

On a real memory POP»ll**# only one stack exists^ and this stack must 
be multiplexed to service the user tasks^ the Executive^ and the 
Executive Sub»systems, 

The RSX«llM System supports n levels of user mul t 1 •programml ng and 250 
levels of user priority. The user establishes the priority of his 
task and the Executive dispatches user tasks based on the highest 



* Section XXX, XXX describes this Initialization, 

** See Section x,xxx for the details of mapped memory systems. 
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priority user task which is ready to run. The System Task Directory 
C8T0)# which is composed of one l8«»word STO Entry (Task Control 31ock 
CTCB)) for each user task in the system, and which is ordered by 
priority* is scanned to dispatch user tasks. 

Having only a single stack also implies a single processor state. The 
Executive must simulate a two state system, A single word, the stack 
depth indicator (SSTKDP), is used to control this simulation. 

When the stack depth indicator is eaual to 1 the system is running in 
the user statei when it's zero or less, it is in the system state. 
All stack multiplexing is accomplished by testing the contents of this 
word. In passing* we should note that the priority set in the PS word 
for user tasks (both privileged and unprivileged) is 0, and for 
Executive routines, when running i nterruptabl e, is either 0# 7 or the 
level at which the interrupt was taken. It is a design goal to 
operate the Executive and its associated routines non»i nterruotabl e 
for as short a duration as possible, we currently estimate the system 
never remains non- i nt e r rupt ab 1 e for more then twenty instructions with 
the typical span of non*i nterruotabl e codes being less than ten 
instructions. Furthermore* the total non*i nterruptabl e time will be 
less than 1/10 of IX of the total processor time. 

External interrupts can occur within the system from either of the 
simulated states, that is when the stack depth indicator is 1 (user 
state) or <»0 (system state). Processor traps* which include the EMT 
instruction used for Executiv© Directives, only occur in the user 
state* with tHe following exceptions! 

TRAP Instruction 

Powerf ai 1 

Describing the RSX-UM interrupt mechanism involves several 
interrelated routines* and it may be necessary for the reader to make 
two passes over this section before the process becomes completely 
clear* To ease your passage* we introduce now a brief description of 
the basic routines involved. 

The RSX-UM interrupt machinery involves the following routines or 
routine types! 

Interrupt processor (both external interrupts and traps)! 
The Interrupt Save Routine ($INT8V)j 
The Directive Save Routine ($DIRSV)> 
The Interrupt Exit Routine (SINTxT)f 
The Directive Exit Routine (lOlRXT), and 
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The Fork Processors ( SFORK , SFORKP', SFORK n , 



Interrupt processors are entered directly and usually call 5INTSV or 
SDIRSV for common save and state sw<tcH<ng servicesi at tHe completion 
of these services* th© interrupt routines are again given control to 
complete the interrupt service. The exit routines SINTXT and SDIRXT 
restore tha state prior to switching to the system state* control the 
un-nesting of interrupts^ and make checks on the state of the system 
(for example, is it necessary to redispatch the processor). The Fork 
Processors lineariie access to shared system data bases* The details 
of all these routines will emerge in the upcoming narrative. 



3,2t3 External 
i ndi cator«l ) 



Interrupt From 



The 



Task 



State 



(Stack 



Depth 



The vectors in lower memory contain a PC unique to each interrupting 
source* and a PS set with a priority of PRT. Hence# when an external 
interrupt occurs* the hardware pushes the current PS and PC 
current stack (in this case the users stack) and loads the 
PS (set at PR7) from the appropriate interrupt vector. The 
routiner then starts executing with interrupts locked out, 
routines may, in fact, be executing in one of three statesi 

I, At PR7 with interrupts locked outi 



onto the 
new PC and 
i nter rupt 
Interrupt 



2« At the priority of the interrupting sourcej thus, 
levels greater than the source are permitted* or 



i nter rupt 



3, At Fork level which is at PR0, 

State 2 is discussed shortly', state 3 will be deferred to Section 
3,2i7t2 (Fork Processes)? for now, lets look at the PR7 statet 



By internal convention, processing in the PR7 state (Interrupt 
processing state 1) is limited to 100U8« If processing can be 
completed in this time, then the interrupt routine simply RTI's; the 
interrupt has been processed and dismissed with minimal overhead. 

If the interrupt routine reauires additional processing time (but does 
not intend to alter a shared system data base) it calls the routine 
SINTSV (Interrupt Save), The priority at which the caller is to run 
immediately follows the call to SINTSV, 

Interrupt save uses the specified priority to set uo the interrupt 
routine such that it is i nterrupt abl e by priorities higher than that 
of the interrupting source (interrupt processing state 2) and 
conditionally switches to system state if the processor is not already 
/n system state. The SINTSV algorithm isi 
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i^INTSVl 



Push R5 and Ra onto the current (user's) stack. 



Decrement stack deotH indicator 



Is the stack depth indicator =0? Not go to 1 



Save the current (a task's In this case) stack oointer 



Set UP the system stack pointer (switch stacks) 



1. 



Load the new processor priority as specified by the caller 



Return to caller. 



Notes I 



The Stack Depth Indicator is zero only when the transition from the 
user state to the system state has occurred. The user state value of 
1 was selected to simplify the decrement* test# and branch which 
establishes whether a stack switch is rieeessary. 

Pushing of R4 and R5 is done to free these registers for routines 
processing external interrupts. It is an internal programming 
convention that assumes these routines will not reauire more than two 
'•agisters to accomplish their functions. If they do# they must save 
and restore any additional registers they use. 
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Example use of SINTSV* 



4 

RKll DISK CONTROLLER INTERRUPT SERVICE ROUTINE 

THIS ROUTINE IS ENTERED VIA THE VECTOR AT LOCATION 22?^ WHEN AN 
INTERRUPTING CONDITION IS DETECTED IN THE RKll CONTROLLER, THE 
ROUTINE IS ENTERED AT PRIORITY PR? WITH ALL INTERRUPTS LOCKED OUT, 



SOKINTJIMOV PS, TEMP MfSAVE VECTOR PS WORD 

CALL $INT8V,PR5 jnSWITCH STATES AND PRIORITY TO PR5 



> CONTROL IS REGAINED AT THIS POINT IN SYSTEM STATE WITH A PRIORITY OF 
f PR5, REGISTERS R^ AND R5 HAVE BEEN SAVED AND MAY BE FREELY USED. 



MOV TEMP, pa inRETRIEVE SAVED PS WORD 

BIC #177760, pa MfCLEAR ALL BUT CONTROLLER NUMBER 



etc. 

Implementation notei 

The CALL macro in the above example is a special form whicH is defined 
in the executive macro file RSXMC.MAC, This file must be concatenated 
with all assemblies using this form of CALL, The code generated from 
the macro expansion isi 

JSR R5,$INTSV 

.WORD *C<Priori ty>&PR7 



3,2,4 External Interrupts From The System State (Stack Depth 
indicator <«0) 

The code on this interrupt path is identical to that discussed in 
Section 3,2,3, However, it is not necessary to switch states when 
SINTSV is called. The current stack is the system stack, and the test 
on the value of the stack depth indicator will cause the saving of SP 



* We intend to make extensive use of examples throughout this manual 
and will repeat coding sequences where necessary to relieve the 
reader from continually paging to find another related example. 
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and the switching of stacks to be bypassed. After saving Pa and R5 on 
the system stack, a return to the interrupt routine is executed. 
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3,2,5 Ppocessop Traps From The Task State (Stack Depth IncHcatop»l) 

When a ppocessop tpap occups from the task state, the hapdwape pushes 
PS# PC# and initiates the routine specified in the associated hapdwape 
tPap vectop. If the tpao was an Executive dipective (E^T 377)i the 
DPB (Dipective Papawetep Block) op its addpess was pushed onto the 
usep's stack ppiop to the issuance of the EMT, The tpap routine, 
punning at PR7 immediately calls th#» poutine $0IRSV (Dipective vSave) 
which has the following algopithmj 

SDIRSVi Push R5 and Ra onto cuppent (usep's) stack 
Oecpement Stack depth indicatop 
Is the stack depth indicatop »07 No# go to li 
Save cuppent (usep's) stack pointep 
Set UP system stack pointep (switch stacks) 
I, Push R3#R2#Rl»R0 onto cuppent (system) stack 

Load new ppocessop priority as specified by the caller 
Return to ca 1 1 ePt 



Notesi 

The depth indicator check is made to improve crash analvsisf no other 
decisions are made in SOIRSV .since all processop tpaps, with two 
exceptions, occup fpom the task state. The exceptions ape handled on 
exit. All pegisters aPe saved! the need fop only two pegisteps, R5 
and R4 is assumed only fop routines processing external inteppuptSt 
As with SINTSV the ppiority at which the caller expects to Pun 
immediately follows the call. All ppocessor trap poutines, howevep, 
run at level 0, 

Only one processor trap can be queued for processing in the system at 
any point in time (ignore, for the moment, the two exceptions we have 
noted). Since the processor trap occurred in the in task state, 
entrance to the Executive occurs only when the Executive is idle. 
While in the System State, only external interrupts can occur. If 
processor traps occur, then either they are valid exceptions, op the 
system itself has faulted and will shut down. 

Once a valid processop tpap is pending, it will be ppocessed to 
completion befope any othep system POUtine is given access to any 
shaped system data base. We will see how this stPict seouent i a 1 i t y is 
effected when we discuss the two exit poutines and the fopk 
processops. 
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Examole use of SDIRSV 



EMT TRAP PROCESSING ROUTINE 

THIS ROUTINE IS ENTERED VIA THE VECTOR AT LOCATION 30 WHEN AN EMT 
INSTRUCTION IS EXECUTED, THE ROUTINE IS ENTERED AT PRIORITY PR7 
WITH ALL INTERRUPTS LOCKED OUT, 



semtrpmcall 

TST 
BEQ 
CRASH 

10St 



SDIRSV, PR0 

SSTKOP 

10$ 



niSWITCH STATES AND PRIORITY TO PR? 
fEMT EXECUTED FROM SYSTEM STATE? 
|IF EQ NO 
KRASH SYSTEM 



etc. 



Implementation notei 

The CALL macro In the ebove example Is a special form which is defined 
in the executive macro file RSXMC,MAC, This file must be concatenated 
with all assemblies using this form of CALL, The code generated from 
the macro expansion ist 

JSR R5, SDIRSV 

.WORD •C<Priori ty>&PR7 



3,2,6 Processor Traps From The Sy,stem State (Stack Level <a0) 

Only two processor traps are valid from the system statei The trap 
instruction and powerfail. If any other processor trap occurs while 
in the system state, the system's opo^ation is aborted. 



3,2,6,1 Processing For Trap Instructions Which Occur In The System 
State 

The trap instruction is used within the Executive as a core saving 
technique in returning status following the processing of an Executive 
Directive, The EMT 377, which is the processor trap used to initiate 
directives, causes entry into the Directive Dispatcher (SEMTRP) which 
in turn calls SDIRSV, on return from SDIRSV, but before calling t^e 
directive processing routine (and entry to the proper routine is via a 
CALL)# the Directive Dispatcher pushes a value of onto the system 
stack, and clears the C bit in the PS word stored on the users stackj 



PAGE 13 



then it calls the proper directive 
directive. Figure 3,1 shows the 
for botH the unmapped and mapped 
the directive processing routine. 



orocessing routine to effect the 
state of the user and system stacks 
systems at the time entry is made to 



UNMAPPED SYSTEM 



USER'S STACK 
DPB 



PS 
PC 



R5 



TOS' 



SYSTEM STACK 
R3 



R2 
PI 



R0 



RETURN AODR 



TOS 



MAPPED SYSTEM 



TOS' 



USER'S STACK 
J DPB I 



SYSTEM STACK 
PS 



PC 
R5 



R4 
R3 



R2 
Rl 



RC? 



+ 1 



RETURN AOR 



TOS 
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FIGURE 3-1 



The Directive processing routine now carries out its function, and in 
so doing is free to alter any shared system data base» since no other 
routine wiH gain access to a shared data base until the directive 
processing routine is completed. This arrangement of the stack and 
interface between the Directive Dispatcher ana the Directive 
Processors has two advantages! 

1. The normal return for aH but a few directives is a +1 status 
and carry clear. This means the directive routines can 
return to the dispatcher with an RTSf thus the return oath is 
one word rather then two if a JMP were employed; this scheme 
probably saves IPif? words in the RSX^llM Executive, 

2, Internal Executive routines can call the directive processing 
routines without using an Emt, 

If a directive processing routine needs to return a status' other than 
+U and have carry clears the routine simply replaces the on the 
stack with the value it intends to return and then executes an RTS, 

Now we come to the use of the trap instruction within the Executive, 
If a directive processing routine needs to return a status other than 
H and, in addition have carry set, or cleared, based on the status 
value returned, then it uses the trap instruction with the value of 
status to be returned in the low order byte of the instruction. When 
the trap processing routine is entered, it immediately checks for 
stack deptha0, and if 0, proceeds to reset the stack for correct 
exiting from a directive processing routine. The low order byte of 
the trap instruction itself overlays the +1 status currently on the 
stack; this value is tested and, if minus, carry is set in the user PS 
word, if plus, carry is left cleared. Then the exiting code of the 
Directive Dispatcher is entered Just as if the directive processing 
routine had executed an RTS, 

If the initial test for a stack depth indicator of <3 fails* then the 
trap processing routine calls SDIRSV, This call is logically 
incorrect if the stack depth indicator was less than zero. This 
programming error is recognized on exit. On return from SDIRSV, the 
trap processing routine checks the stack depth indicator, and if it is 
not lero, the system is shut down. 

Note that directives are legitimate only from the task state (stack 
.depth indicator*!) to that during directive processing, the stack 
depth indicator is always 0t Interrupts that occur in system state 
disappear from the stack before the directive processing sequence 
resumes following an interruptt Hence, even though the stack can grow 
while a directive processor is in control, this growth is transparent 
to the directive processor. Stating it from a different perspective, 
interrupts are Permitted but the directive processor in control is 
unaware of them. 
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Directive procesting routine* thus have three methods returning 
St atus I 

1, For the norma! return carry clear and status equal to +1# use 
an RTS, 

2, For carry clear and status other than +1, overlay the +1 
status on the stack with the desired status value Cstatus 
value is at 2CSP5^# and RTS. 

3, For carry clear or set^ and status of one byte# use tHe trap 
instruction, This requires more overhead than I and 2 above 
but saves core^ and# of course is the required return 
mechanism if carry is to be set, 

TogetHer^ these return mechanisms from directive processing routines 
save between 200 and 300 words in the RSX*UM Executive as compared to 
returning via Jump instructions. 



3,2,6,2 Powerfail Processing 

When a power failure occurs* the power failure trap processing routine 
is entered. This routine saves the state of the system* sets up a new 
power failure trap»vector PC for use when power is restor«cl, then 
HALTS, 
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On restoration of poweri the state of the system at the time the 
failure occurred is restored, a flag is set by software indicating 
that a power failure has occurred, the reschedule oointer* is set to 
the null task, and the clock is re-enabled. Then, the restoration 
code issues an RTI, which results in the resumption of the processing 
that was in progress when the power failure occurred. The specific 
processing to reflect the occurrence of a power failure will not occur 
until either Directive Exit is entered or the clock interrupts. In 
any event, this processing is part of Directive Exit and will be 
discussed under Directive Exit, 

Note that power failure processing is not asynchronous. As much as 
1/60 of a second could elapse following restoration before the power 
failure is acted uPon, 

The records and logic needed to provide asynchronous processing are 
simply too large for a system witH RSX-UM's core objectives. Our 
assumption is that asynchronous power«f ai 1 ure processing is not 
consistent with RSX-llM's objectives or markets. 



3,2,6,3 Aborting The System 

^hen a condition is detected that indicates the system should be shut 
down (crashed in an orderly manner), the detecting routine issues an 
lOT, The lOT processing routine, as usual, calls Directive Save, and 
on return checks for a stack depth equal to xero. If equal, normal 
SST processing is entered. If not equal to lero, the routine SCRASH 
is entered. Crash displays, on the device whose CSR address is 
CSSRSH, an appropriate printout which is detailed in Appendix I, 
After completing the printout, it Jumps to a routine called SPAMC, 
which optionally prints out an edit of selected memory locations. In 
the minimum system both SCRASH and SPANIC are condi t i onal i zed out, and 
a system crash simply results in « processor halt at location 560(8), 



3,2,7 Processing Within Interrupt Routines 

In Section 3,2,2 we examined interrupt entry into the RSX-llM 
Executive, In this section we detail the events which take place 
following interrupt entry up to the point where the Executive is ready 
to return control to the task state. 

Once the Executive is entered via an interrupt (regardless of the 
state its in when the interrupt occurs) it will not again return to 



The reschedule pointer will i be covered when we discuss task 



swi tch i ng. 
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the tasl< state gntH all system related processing for tHat interruot 
Has been completed* From another point of view# the task state Is 
never in control unless the Executive Has not h i ng- to-do (is idle). 

While in the task state a single interrupt causes transfer into the 
system state where the system remains until the interrupt is 
processed. But while in the system state, repeated interrupts can 
occur. This implies a fixed interrupt depth of one for the task stack 
(requiring a task to provide a stack of at least four words in an 
unmapped system), and implies a variable interrupt depth for the 
system stack. 

If interrupts can occur in the system state, then a mechanism is 
required to prevent unwanted recursion and improper data base 
modification. In RSX-llM both of these logical difficulties are 
resolved by strictly linearizing interrupt processing and access to 
internal data bases. The mechanisms employed to accomplish this 
linearization are the system stack, fork processes, and the associated 
fork list, 



3,2,7,1 Queuing Interrupts On The System Stack 

In the system state the goal is to operate i nter rupt i bl e as much of 
ihe time as possible. Three conditions exist when the system itself 
runs non»i nterruptabl ei 

1, The most recent interrupt is being processed at level PR7 and 
the interrupt routine has not yet returned to an 
i nterrupt i bl e state, 

2, The interrupt routine has dropped from level PR7 to the level 
at which the interrupt occurred. Priority levels, eaual to 
or less than the priority of the interrupting source are 
locked out, 

3, The system is updating a critical list whose consistency can 
only be maintained by a non*i nterruptabl e instruction 
sequence. There are two such lists, ahd we will discuss them 
short 1 y. 

In Sections 3,2,3 and 3,2,^ we examined the code sequence for 
processing external interrupts and processor traos, as well as the 
stack additions that occurred during their processing. Interrupt 
stacking in the system state will occur based principally on hardware 
interrupt levels. Thus if a level PRa interrupt is being processed* 
then a level PR5# PR6# or PR7 interrupt can potentially interruot this 
processing and cause context to be stacked and control given to the 
higher level interrupt routine. 
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3,2,7,2 Fork Processing And The Fork List 

Once an interrupt routine passes frow a non-i nterruot i bl e to an 
i nter rupt i b1 e state via a call to SINTSV, processing is at the same 
level as the priority of the interrupting source. Along any given 
interrupt path however, more processing is often required than the 
goal of minimun non»i nterupt i bl e code sequences in the Executive 
permits! along this path the allowable maximum non*i nterrupt i bl e 
orocessing time is 500us, Thus# a scheme is required to split 
interrupt processing routines further, such that part of their 
execution runs i nt e r rupt i b 1 e to any interrupting source. The 
mechanism for achieving this split is called fork processing. Fork is 
an internal subroutine with three entry points? fork linearizes 
accesses to system data bases, thus eliminating unwanted recursi on 'and 
mul i tpl e-updates of these data basest An associated list, the Fork 
List, which is processed FIFO, is used as the linearizing structure, 

Interrupt routines are required to adhere to the following internal 
convent i ons i 

1, Use of any registers except and R5 requires that these 
registers be saved and restored, 

2« Nen»i nterrupt i bl e processing must not exceed twenty 
i nst ruct i ons, 

3, All modifications to system data bases must be done via a 
fork process. The first two requirements are 

straightforward, so lets turn our discussion to Fork, 

Along an interrupt path, control can be taken from a routine only due 
to a higher priority interrupt pending in the hardware. As discussed 
previously, these interrupts are keot track of on the system stack. 
When an interrupt routine needs to transfer from a noni nter ruPt i bl e 
(including partial non* i nter rupt i bi 1 i ty) to an i nter rupt i bl e state, or 
modify a system data base, it must call Fork, Fork, however, cannot 
be called directly from an interrupt routine? it must first switch to 
system state by calling Interrupt Save and then call fork. 

Fork has three entry points depending on the size of the fork block 
being provided by the caller for context storage, 

SFORK requires a a-word fork block which contains^ 

A forward link in the fork list 

PC of the call er 

Saved Ra 



Saved R5 
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iFORK Is fop I/O drivers and the fork orocessor assuT^es ^5 is loaded 
with the unit control block (UCB) address, 

SFORKl requires a 3-word fork block containingi 

A forward link in the fork list 

PC of the caller 

Saved R5 

SFORKI^ reauires a 2«word fork block containing^ 

A forward link in the fork list 

PC of the call er 

SFORK when cal 1 edi 

Stores the return PC# R5 and Ra* into the fork block. Appends 
the supplied fork block to the fork list# and Juwps to Interrupt 
Exit, 

By virture of calling fork, the routine is now i nter ruot i bl e and its 
access to system data bases is strictly linear. The interrupt 
(Drocessing routine is now in state 3, (Refer to Section 3,2,3 for a 
discussion of states t and 2), The Fork List is a list of system 
routines waiting to complete their processing, in particular, waiting 
to access a shared system data base. 

When the Fork routine* after placing the fork block in the fork list» 
Jumps to SINTXT the stack items for the interrupt routine are removed 
from the stack. In effect the fork list is a secondary interrupt 
queue (stack) whose members are processed FIFO# and obtain processing 
time only if the system stack is empty. 

Note that the context saved for a caller of SFORK depends on which 
entry point is cal1ed# and the context saved is all that is needed to 
restart routines on the fork list. 



* R5 and R<i will or will not be stored depending on which variant of 
Fork is call ed. 
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Exampl e call to $FORK 



RKll DISK CONTROLLER INTERUPT SERVICE ROUTINE 

THIS ROUTINE IS ENTERED VIA THE VECTOR AT LOCATION 220 WHEN an 
INTERRUPTING CONDITION IS DETECTED IN THE RKll CONTROLLER, THE 
ROUTINE IS ENTERED AT PRIORITY PR? WITH ALL INTERRUPTS LOCKED OUT, 



SOKINTI IMOV 


PS#TEMP 


IMSAVE VECTOR PS WORD 


CALL 


$INTSV,PR5 


niSWITCH STATES AND PRIORITY TO PR5 


MOV 


TEMP,Ra 


fflRETRlEVE SAVED PS WORD 


BIC 


#177760, Ra 


niCLEAR ALL BUT CONTROLLER NUMBER 


ASL 


Ra 


f>;CONVERT TO WORD INDEX 


MOV 


CNTBL(Ra) ,R5 


MiRETRIEVE ADDRESS OF UCB 


TSTB 


RTTBLflCRa) 


nrORIVE RESET IN PROGRESS? 


BEQ 


50S 


n > IP EQ NO 


• 

drive 
• 


reset processing 


code 


50SI CALL 


SFORK 


ftfCREATE A FORK PROCESS 



f 

S CONTROL IS REGAINED AT THIS POINT WITH ALL INTERRUPTS ALLOWED, 
I 



3,2,8 Exiting The System State 

In Section 3,2,2 • 3,2, 7#2 we covered the Executive's processing of 
interrupts, and the methods employed to Hnearize their processing so 
as to minimize the non»i nterrupt i bl e time spent in the system statet 
In several places we referenced two routines SINTXT (Interrupt Exit) 
and SDIRXT (Directive Exit). These routines result in the sequential 
removal of all items on the system stack, then all items on the fork 
list. It is these two routines to which we now turn. 

The Executive's strategic objective is to return to equilibrium (the 
idle state) as fast and as efficiently as possible? its tactics to 
achieve equilibrium is to is to service all routines on the system 
stack first. These routines are usually running at some level of 
non-i nterrupt i bi 1 i ty , when the system stack is cleared of pending 
requests* the Executive then services the pending requests on the fork 
list. When both the fork list and system stack are empty, the 
ExecutiVf will either return to the task state or if no task is 
active, drop into the Null Task, 

tINTXT is transferred to by external interrupt processing routines 
that are running on the system stack at the Priority of the 
interrupting source (state 2 for those interrupt processing routines). 
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^OIRXT Has the task of aervlcing tHe fork Hst and* when the Executive 
haa no more work to do* restoring the task statet SDIRXT <s entered 
by trap routines* fork routines* and by SINTXT. 



3,2.8,1 Interrupt Exit CSINTXTD 
The SINTXT algorlthffl Is as follows* 
SINTXTt Lock out Interrupts 

Is stack depth 1nd1cator«0? No* So to 1, 

Is fork list empty. Yes* go to 1, 

A 1 1 ow 1 nter ruot s. 

Store R3*R2*Rl*R0 on the current (system In this case) stack 
Jump to SOIRXT (Directive Exit), 
1, Increment stack depth Indicator, 

Restore R4 and R5 from current stack and RTI, 

Notesi 

Interrupts must be locked out to Insure a consistent check of the 
stack depth Indicator and the contents of the fork list. The same 
type of lockout occurs In Directive Exit, There are two 
non-lnterrupt Ible code spans used to check and uodate the fork list 
mentioned In Section 3,2,7,1,* one In $FORK, and one In SOIRXT, The 
saving of R3 thru R0 Is prepatory to the jump to SOIRXT which expects 
these registers on the stack. Note that the path through the 
Executive which find both the fork list emotv and the stack depth 
Indicator equal to Is fairly common. As can be seen* this Is the 
minimum overhead path. 



3,2,8,2 01 recti ve Exit 

The SOIRXT algorithm Is as followsi 

SDIRXT: Lock out Interrupts, 

Is the fork list empty? Yes* go to I, 
Uodate Fork list pointers, 
A 1 1 ow 1 nterrupt s. 
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Restore Fork context. 

Call routine whose fork context was restored. 
Go to SDIRXT. 

1, Is rescheduling required (SRQSCH not«0)? No> go to 2, 
Allow 1 nt errupt 8, 

Clear SRQSCH, 

Save context of current task. 
Locate a readv«to*run task. 
Restore context of new task, 
Go to SOIRXT, 

2, Is the power failure flag set? No# go to 3, 
Allow i nter rupt 8 

Call power failure processing. 
Go to SDIRXT 

3, Restore task stack pointer. 
Increment stack depth indicator. 
Restore R4 and R5 from user stack and RTI, 

Notesi 

SDIRXT calls both waiting fork processes and the powerfail routine. 
These routines terminate via a RTS instruction. On return SDIRXT 
again cycles looking for work. 

The task reschedule pointer SRQSCH controls the redi soatch i ng of the 
processor, It points to the location in the STO list where SDIRXT 
should begin its scan for a task ready to use the processort 

SRQSCH is set when a change of state has occured in the system that 
wight cause a task other than the one currently in control to obtain 
processor timet Examples are I/O done# clock aueue runout, or a task 
doing an EXIT, THe word is reset by SOIRXT Just prior to its 
dispatching a new task. 
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3,2,9 Interrupt Processinq Summary 

Seven routines or groups of routines not only compplse the interruot 
system but can be said to oractically comprise tHe entire Executive 
i tsel f , 

External Interrupt Routines 

Trap Routines 

Interrupt Save 

Di rect i ve Save 

Fork and Fork Processes 

Interrupt Exit 

Oi rect i ve Exit 

External interrupts cause traps to external interrupt orocessing 
routines which run in one of three statesj 

1, Non- i nter rupt i p1 e at PR7, 

They run here when initially entered, 

2, Inter rupt i bl e by priorities higher than the interrupting 
source. 

Both states I and 2 are linearized being queued and dequeued 
from the system stack, 

3, Fully i nterrupt i bl e as fork processes, 

Trsp routines ^of which only one may occucy the system stack during 
any given passage through the Executive^ operate at priority level 
iero» need never call Fork, and operate entirely from the system 
stack. 

Interrupt save is called by external interrupt routines when they make 
a transition from state I to state 2, 

Directive save is called by trap routines. 

Fork creates a fork process for external interrupt routines. 

Interrupt Exit unstacks waiting routines executing from the system 
stack, and when the system stack is empty drops into Directive Exit, 

Directive Exit has the Job of giving control to waiting fork 
processes, orocessing power failure, and redi soatch i ng the processor. 
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The Executive structure Has an imoHed sequentlaHty whicH obviates 
the need ^or any explicit synchronizing mechanisms. System routines 
which follow the internal conventions of the Executive never need 
concern themselves wi t h mul t i ol e-uodate of shared system data bases. 
In tending toward the idle state the Executive gives priority to 
routines on the system stack* then to fork processes. 
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3,3 I/O Ppocessii^g 



3,3.1 Goals 

The I/O interface 1$ 100% cofnoatible with RSX-llO, i»i<tHin the 
pequirement of compat i b i H t y i three goals guided the design! 

1, The total wemory for I/O processing (data structures olus 
drivers) must be reduced by 50% vs RSX-llD, 

2, The I/O data structures should have substantial flexibility 
for adding future devices* or for altering the service 
discipline of existing devices. 

3, Throughput should equal or exceed »3X-nO's, 



3,3,2 I/O Philosophy and Functional Overview Of Its Implementation 

To meet its stated goals, the RSX-UM I/O system attempts to 
centralize common functions, thus eliminating the repetitive 
c^i^pearance of code, which is almost identical in form and function, 
^com appearing in each and every driver in the system. To achieve 
this, a substantial effort has been expended in the design of 
RSX»UM*s I/O data structures which are used to drive the centralized 
routines. The effect is to substantially reduce the size of 
individual I/O driversi an RSX*llM driver is typically one-fourth as 
large as its RSX-UD counterpart. Of course, the centralized code, 
and an increase in the size of RSX»llM»s data structures compared to 
RSX*llD*s reduces our effective size reduction. But, on the balance, 
we have substantially reduced the size of our total I/O processing 
core reouirements while at the same time . produced a more 
understandable, maintainable, and enhanceable I/O system (obviously, 
our subjective judgement). 

The user interface to the RSX<»llM I/O system consists of logical unit 
numbers (LUNs) and a single active I/O directive QUEUE I/O, (The 
directives ASSIGN LUN, GET LUN INFO, etc, do not initiate I/O 
transfers). 

In RSX-llM all the preliminary processing antecedent to actually 
queuing an I/O request is performed by the 010 directive processing 
code which is driven from the I/O data structures^ this code calls 
ancillary routines for centralized services, when a driver finally 
receives an I/O order, it has very little to do other than set up the 
status registers and issue the order. 

Termination processing is equally modular and centralized. The driver 
is entered, performs some cleanup operations, and calls centralized 
routines for obtaining pending I/O orders, performing AST processinq, 
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etc. The driver is only concerned 
details of the actual hardware inte 
and comoletion of I/O trans 
ohi1o80Phv» RSX-llM keeps both d 
orocessing time small. 



with the most intimate and soecific 
rface in rescect to the execution 
fers. Using tnis centralization 
river size and non- i nt e r r uot i b 1 e 



3,3,5 RSX-UM I/O Data Structures 

The static* I/O date structures consists of three distinct entities! 

1, A Device Control Block (OCB)i 

2, A Unit Control Block (UCB), and 

3, A Status Control Block (SCB). 

Although each serves a soecific function, and the components of each, 
in generali reflect tHese functions* the coherence achieved by a 
strict set of rules for determining into which data structure a 
specific unit of information would be placed was ultimately sacrificed 
to core savings and code efficiency. The exceptions* however* are 
few, and the functional purpose of each data structure is reflected by 
^^he units of information which compose them. 



3,3,3,1 The Device Control Block (OCB) 

One device control block exists for each device type attached to the 
system. Its function is to describe the static characteristics of 
both the controller and the units attached to the controller. All the 
OCB's in the system are singly linked. The DCS contains such 
information ast 

The device mnemonic CTwo ASCII characters) 

The lowest and highest Unit Numbers on the respective Controller 
The address of the first uCB 
The Length of Each UCB 
The next DCB Pointer 
The Legal Function Mask 



* Static in the sense that they are established at SYSGEN and only 
anotHer SYSGEN can expand or contract the number of I/O units served 
by the structures. 
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The Control Function Mask 
Th« (slo*Op'd Function Mask 
THe File Funct i on Mask 

The Pointer to the Driver Dispatch Table 

All these information units are static and are used principally by the 

QUEUE I/O directive processing code to oreoare a Queue I/O reauest for 

a device driver. The details of QUEUE I/O Processing are in Section 
3.3.5, 



3.3,3.2 The Unit Control Block CUCB), 

One unit control block exists for each physical device unit attached 
to thf system. Many of its information units are static, though it 
does contain a few dynamic parameters. For example the redirect 
pointer which reflects the result of a Redirect mcr command. 

The UCB contains device unit specific data, such as unit status* 
Physical unit number, and unit characteristics. 



3.3,3.3 The Status Control Block (SCB), 

One status control block exists for each device controller in the 
system. This is true even if the controller handles more than one 
device unit (like the RK Controller), Line multiplexers such as the 
DHll and Ojn are considered to have a controller oer line since all 
lines may transfer in parallel. 

Most information in the SCB is dynamic. It contains the following 
information about the currently active unit! 

The Interrupt Vector Address 

The Controller Bus Request Priority 

Timeout Counts (Initial and Current) 

The Address of the Control Status Register 

The Address of the Current I/O Packet 

Storage For A Fork Block 

The I/O Queue Listhead 
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The Cor^troller Status (Busy/Irne) 

The Cont ro 1 1 er Index 

As can be seen^ the SCB is quite dynamici makMg it Dossible to 
maintain control of the current I/O in orogress on the contPoPer. 
The presence of the fork block storage in the SCB implies I/O 
linearity for the processing at fork level on a given controller. We 
have here a specific example of how multiple updates and recursion are 
controlled. The driver for a specific device tvoe never concerns 
itself with unwanted recursion or multiple updates. Once a driver is 
in a fork level process, further I/O processing, which nnay involve 
updating a shared data base, is automatically locked out by the 
structure of the system itself. 



3,3,4 Some Sample I/O Structures 

Figure 3-2 shows the data structure that would result for three 
terminals each interfaced via a OLll asynchronous line interface. The 
structure requires three UCBs and three SCBs since the activity on all 
three units can proceed in parallel. In Figure 3-3 the internal data 
structure for an RK disk controller with three units is depicted; 
^ote that only one SCB exists because only one of the three units may 
he active at any time. 
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3,3,5 Queue I/O Directive Flow 



The Queue I/O directive requires the Issuer to construct a twelve word 
directive parameter block as shown in Figure 3-^, 
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1 FUNJCT CODE 




MODIFIER i 


I RESERVED 


i 


LUN I 


I PRIORITY 


I 


EFNi I 


I I/O STATUS 


BLOCK 


ADDRESS I 


I AST 


ADDRESS I 


I DEVICE I 



DEPENDENT 
PARAMETERS 



Figure 3»4 

The parameters have the following Interpretation, 
Length Crequired)l 

The length of D^B, For 010 always eaual to twelve words. 
Die (reauired)i 

Directive Identification Code, For QIO# the value Is a 1, 
Function Code (reaulred)! 

The code of the requested I/O function (0 thru 31,), 
Modi fieri 

Device dependent modifier bits. 
Reserved! 

Reserved bvte and mgst not be used, 
LUN (requlred)i 
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Logical Unit Number, 
Pri ori ty I 

Request priority. Ignored by RSX-llM, but space must be 
allocated ^or RSX-UO compatibility, 

EFN (oPtionani 

Event f 1 ag number, 

I/O Status Block Address (ootional)i 

This word contains a pointer to the I/O status block which is a 
4»byte device dependent I/O completion data packet formatted as? 

Byte (? 

I/O status byte 

Byte 1 

Augmented data supplied by the driver 
Bytes 2 and 3 

The contents of these bytes depend on the value of byte l^. 
If byte 0Bl then these bytes contain the processed byte 
count. If not5l# then the contents are device dependent, 

AST Address (optionaUJ 

Address of an AST Service Routine, 

Device Dependent Parametersi 

Up to six parameters specific to the device. Typically these 
are t 

Buffer address 

Byte count 

Carriage control type 

Logical block number 

Any optional parameters that are not specified must be filled with 
zeros. 

When the QIO directive is issued, QIC directive processing code 
receives control and processes the reouest as follows! 
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It [Perform first level vaHdity checks] 

QIO exafnines the LUT (LogUal Unit Table) <n the task header 
for a LUN match. 

It checks if the LUN is legal for the requesting task. If 
the LUN is greater than the available LUT slots established 
for the task the directive is rejected. Given a valid LUN, a 
check is made to determine if a valid UC8 pointer exists in 
the LUT for the specified LUN, If none exists the directive 
is rejected. If the LUN and UCB pointer are valid, the 
redirect algorithm is entered, 

la, [Redirect algorithm] 

The UCB is located and the re«direct pointer checked. If the 
re<"direct pointer points to the UCB which contains it# then 
the final link in the redirect chain has been found. Else 
the redirect UCB address is obtained and the test is 
repeated. This search continues until the last re-directed 
UCB is found. Then, the backpointer to the DCP is used to 
locate the DCB and a check on the device name is made. If 
the name is TI, then the address of the UCB which is to be 
used to control I/O transfers is in the TCB of the reauesting 
task. This pointer was implanted by mcr when it requested 
the task and the chaining process described links the 
requesting task to the terminal which requested it. If the 
name is not TI> the final UCB in the redirect chain is used 
for the I/O Transfer, The EFN and I/O status block (lOSB) 
address are validated and the priority is ignored. If any of 
these checks fail, the directive is rejected. If the checks 
passi the directive status is set to +1 and the IOSB# <f 
specified* is cleared, 

2, [Obtain storage for, and create an I/O driver queue entry] 

After the first level checks prove positive* QIO obtains an 
18"Word storage block from dynamic storage. Into this block, 
which we will refer to as an I/O packet* QIO inserts the 
following (the source of the data is specified with each data 
i tern) 

Function Code 

Copied from the DPB 

Contents of the first LUN word 

Established by the redirect algorithm 

Address of the second LUN word 

Calculated from the requesting task's header address 

EFN 

Copied from the DPB 
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Priori t>/ 

Copied from TCB of the reouesting task 

Address of the Task Control Block 

The TCB address of the requesting task 

Virtual address of the I/O status block 
Copied from the DPB 

Relocation Bias of the I/O status block* 
Calculated 

Address of the I/O status block^^ 
Cal cul ated 

AST address 

Copied from the DPB 

Device Dependent Parameters 
Copied from the DPR 

3, [Validate the function request] 

Using the 1 ega 1 * f unc t i on mask in the DZB, QIO determines if 
the requested function is legal. If it is not legal, go to 
<>. 

4t [Check for no*op'ed function] 

Using the no*OP'ed function mask in the DCB, check if the 
requested function is to be no*op'ed. If yes# go to 9, 

5t [Check for a Control Function] 

Using the control function mask in the OCB| determine if the 
requested function is a control function. If yes, go to 8, 

6, [Check for a file system function] 

The next tier of function checks determine if the function is 
a file system function. If it is, a check is made to see 
whether the device to which the request is directed is file 
structured. If it is we go to 8, If the device is not file 
structured, then the function requested must be either a read 
virtual or write virtual. The request is mapped to its 
logical counterpart (read or write logical) and processing 
proceeds at step 7, 



* These exist to satisfy requirements of the mapped system, A 
separate section will detail the differences between a mapped and 
unmapped system. 
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7, CTrantfep function processing] 

If the function Is legale but not a no*op or control 

function^ then It's a transfer function^ and address checks 

•re made on the buffer* count* and modulus reaul rement s* , If 
any of these fall* qo to 9, 

8, [Packet Queulngl 

QIO checks the control bits In the UCB which determines If It 
win queue the packet and then call the driver, or call the 
driver and let the driver queue the oacket. The caH to the 
driver Is via the pointer in the DCB to the driver dispatch 
table entry addresses* namely! 

INITIATOR 

CANCEL I/O 

POWER FAILURE 

DEVICE TIMEOUT, 

In this case the Initiator entry point Is called* and normal 
path 010 directive processing Is complete, 

9, [Function Is Illegal* no-op'ed* or Invalid parameters] 

If any of these cases pertain* QIO calls I/O Done and passes 
a status code, A special entry point Is used which causes 
I/O Done to bypass clearing of the unit and controller busy 
flags* Clearing of which occurs along I/O Done's normal path, 

Notesi 

By reviewing the algorithm for the QIO directive processing* the 
reader should note the care taken to relieve the driver of validation 
processing. It's through the centralisation of validation processing 
that driver code Is substantially shortened and structurally 
simpllfledt A beneficial fallout of this strategy Is that drivers are 
not called with requests that are going to either fall on a ore-lssue 
validation check, or not result In the Issuance of an actual I/O (like 
no-op and control functions). This substantially reduces Internal 
overhead. 



3,3«6 Issuing I/O 



* Modulus checks exist for devices which have boundary alignment 
requ 1 rement 8, 



PAGE 35 



Q.IO calls tHe driver at the initiation entry point, win avoid t^e 

subtlety of when packet queuing does not occur and assume it's aueued. 
The driver algorithm is as ^ollowsi 

1, [Get an I/O reauestl 

When the driver is called, it immediately calls the internal 
routine Get Packet (SGTPKT), Get Packet is discussed in 
Section 3«3,6,1, SGTPKT either delivers a packet, or returns 
busy. If busy, go to 3, 

2, II/O Issue] 

The driver builds the actual I/O order and issues it. It 
then returns, in this case to QIO, QIO returns the directive 
status to the user issuing the original QIO directive and 
clears the directive from the stack by returning to the 
directive dispatcher, 

3, [GTPKT returns busy] 

If SGTPKT finds the controller busy, thus making it unable to 
return an I/O packet to the driver, it simply returns a busy 
indication. The busy indication simply informs the driver 
that it cannot at this time issue an I/O order. The driver 
returns to QIO* which returns the directive status to the 
user issuing the original QIO directive and clears the 
directive from the stack by returning to the directive 
dispatcher. The original I/O is in the driver queue, and the 
issuer can take appropriate action (Waitfor or continue). 



3,3,6,1 Get Packet Routine 

Get Packet (SGTPKT) is called when an I/O driver needs work. This 
occurs following a QIO call on the driver, and after a df»iver has 
processed an I/O termination, SGTPKT does not know about the 
initiation cause of a call upon it, it simply attempts to find work 
for the driver end proceeds as followsi 

1. [Scan the driver Q] 

SGTPKT is passed a UCB address, which it uses to locate the 
SCB and the I/O queue. If the controller is busy, SGTPKT 
returns busy to the caller. If the controller is free, a 
queue scan is begun for the highest priority request that the 
driver can initiate. Note that the queue is already in 
priority order and the question to be resolved is whether an 
entry represents work the driver can do. Also note, that if 
a controller is free, all units on the controller are free. 
Each queue entry must be checked to determine if the unit to 
which it is directed is attached. If it is attached, SGTPKT 
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must cHeck \f the attached task is the same as requesting 
task, it isi it returns the packet to the driver. If it 

is not^ it continues the aueue scan. It will either find 
work, or return busy. 



3,3,7 Termination Processing 

On an I/O interrupt (specifically a termination in our present 
discussion) the driver is entered directly. The driver first calls 
SINTSV and then SFORK, Or return from SFORK access to shared data 
bases has been linearized and the driver may finish processing of the 
I/O request. The routine that performs this processing is called I/O 
done, 

I/O Done proceeds as follows: 

The controller and unit are unbusied, (Both the controller and unit 
require busy indicators to enable the Executive to identify the 
eont rol 1 er»uni t busy relationship if a power failure occurs). 

The relocation bias and lOSB address in the I/O packet are used to 

locate the lOSB, If an lOSB was specified then the final status is 

stored, I/O Done then decrements the outstanding I/O count (the I/O 

Count is used to prevent task checkpointing if outstanding I/O's are 

pending for the task). If the count goes to zero* and the task was 
blocked for I/O rundown^ the task is unblocked. 

If a checkpoint request was pending for the taski an internal routine 
is called that will initiate the checkpointing process, 

A check is then made to determine if an AST address was specified! if 
notf the I/O packet is released to dynamic storage^ a significant 
event is declared* and I/O Done returns to the driver. 

If an AST address was specified, the I/O packet is used for the 
required AST dynamic storage and it is linked into the AST listhead 
for the task, A significant event is declared and I/O Done then 
returns to the driver» On return, the driver will Jump to its 
initiator entry point with the address o^ the Just unbusied device UCB 
in R5, The initiator calls SOTPKT and the process of looking for work 
begins again. It should be noted that once underway, either by a call 
from QIO, Or entry from an interrupt terfni nat i on, a driver propagates 
its own execution by cycling back to its initiator entry point looking 
for more work. 



3,3,6 I/O Processing Summary 

RSX»llM I/O drives itself from four data structures! 
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The Device ContPol Blockf 

THe Unit Control Blocki 

The Status Control Block, and 

The l8»word driver queue I/O packet, 

CentraHied routines facilitate both Initiation and termination 
processing. And, finally, the fork structures used by the drivers 
along paths reaulrlnej more than 500us of processing both linearize 
access to the I/O data bases, and decrease the non»1 nterrupt 1 bl e time 
within the system Itselft 
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3.4 MCR * MonUor Con$ole Routine 



MCR Is the collection of functions that make It possible to operate 
and control the RSX»UM system from a terminal device. As the link 
between the collection of services provided by RSX-llM and users who 
want to make use of these services, MCR provides a number of services* 
spec 1 f 1 cal 1 y I 



Services 1-16 run as MCR overlays. 



I, ABOrt 



The task name submitted with the command will be aborted. 



2, ALTer 



The priority of the named task Is altered. 



3. CANcel 



Periodic rescheduling Is terminated for task name submitted. 
The task Itself remains In the STO, and may be active or 
1 nact 1 ve, 



a. OEVIces 



Symbolic names of all devices known to the system are 
displayed on the requesting terminal. The display Includes 
any device redirections. 



5. FIX 



The named task Is fixed In memory. This task cannot be 
checkpol nted, and will remain In memory at task exit. 



6, LUN 



A list of Logical Unit Numbers and their associated device 
tyfPbollcs Is displayed fop the task name submitted with the 
command. 



7, OPen 



Open Is used for examination and/or modification of main 
memory. 



8, PARtltlons 

This command outputs a description of each partition and 
sub»part 1 1 1 on In the system. The list also specifies If the 
partition Is a task or common partition. 
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9, REAtign 

Reassign de-essigns a Logical Unit Nujr^ber from one physical 
device and assigning it to another for the named task, 

10, REDirect 

Redirect makes posible the redirecting of all I/O requests 
from one physical device to another having comoatible 
character i sties, 

11, REMove 

The task named is deleted from the STD, The task so removed 
is unknown to the Executive and exists only as a disk image, 

12, RUN 

This command enables a task to be scheduled in terms oft 
a, A delta time from now^or 

bt A delta time from clock unit synchroni fat i oni or 

c. Absolute time of day* or 

d. Immediate executient 

with options a* b, and c periodic rescheduling is provided, 

13, SAVe 

This command preserves an image of the RSX-llM Executive on 
disk such that a hardware bootstrap or the BOOt MCR function 
can reload and start up the system, 

la, SET 

Set terminal and device parameters, 

15, TASks 

This command outputs a description of every task which exists 
in the STD, 

16, UNFix 

Unfix reverses the effect of FIX, 
Services 17-22 run as tasks, 

17, Boot 
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The Boot Command wi H bootstrap an RSX-llM system from a file 
that was either created by the SYSGEN process or the SAV mcR 
f unc t i on, 

18, DMOunt 

Declares a volume logically off-line, 

INItialize 

Creates en RSX-llM structured volume, 

20. INStall 

The tasi< contained in the file specified in the command is 
entered into the STD# and the task header is initialiied, 

21. MOUnt 

Declares a volume logically on-line, 

22. UFD 

This command creates a User File Directory CUFD5 and enters 
its name into the Master File Directory (MFD), 



3,4,1 Structure And Operational Environment Of MCR 

MCR is an RSX-UM task which operates out of a subpartition which is 
part of a main Partition occupied by the File System*, TKTN, the task 
termination notification taskf also operates out of a subpartition of 
the File System partition. The partition is set up so that the file 
system is checkpointable and either TKTN or MCR can checkpoint the 
File System, Thus, the file system will be swapped out and MCR 
swapped in when an operator request occurs, 

MCR Is a tree structured task, and its structure is depicted 
schematically in Figure 3«5, 



* We mean tHat part of the file system referred to as File Control 
Pri mi t i ves. 
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Figure 3"5 MCR Tree Structure 



The command function processors are those that orocess the first 16 
console services listed In Section 3, a. The remaining console 
services run as tasks and not as Integral parts of MCR, mcr, In fact# 
does not distinguish between these taste functions^ and tasks that It 
Initiates as a result of recognizing an MCR reauest for functions 
17*22 listed In Section 3,^, The console language syntax Is defined 
such that If the first three characters of an Input line are not part 
of the defined command language* then MCR will attempt to Initiate the 
task named 



f • t X K X 

Thus* the task named ,,,JIM can be Initiated by entering 
JIM 

to MCR* or by entering 
RUN ...JIM 

to MCR, 



3.4.2 The Terminal Driver and MCR Initiation 

The terminal driver Is Intimately Integrated Into the operation of 
MCR, Since R8X»llM accepts and acts upon unsolicited Input from any 
operator terminal* It Is the function of the terminal driver to know 
when It Is receiving Input destined for MCR, 

When a character on an operator terminal Is struck* the resulting 
Interrupt Initiates the terminal driver, (Remember the device Is full 
duplex and the keyboard cannot be locked to prevent Input when the 
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cievice isy in fact» iavolved in an I/O operetion). The driver then 
acts on the input «• follows, 

1. [Check the device state] 

Is, the device busy. Ho, go to 3, 

2« [The device is busy] 

If the driver was sending output (in an output state) when 
the character was entered, an input request flag is set in 
the appropriate UCB and the driver continues sending the 
output strearp. When the output reauest is finished, 
processing continues at 5, 

If the terminal was in an input state the character is 
accepted. Go to 6, 

3, [Device is not busy] 

Note, if the device was not busy, the incoming character is 
the first character of an input line. 

Was the input character a Control-C? (ControNC is an 
explicit request to communicate with mcR), If the character 
was a Control«C, the terminal driver executes a fork and 
execution continues at ii. 

If the first character is not a Control*C# then a check is 
fT^ade to see if the device is attached. If yes, then ignore 
the character (unsolicited input to mcr on an attached device 
is not permitted). 

If the device is unattached then it will be considered the 
beginning of unsolicited input to MCR, Go to 4, 

4, [Fork level processing] 

The driver has transferred to fork level because it needs a 
buffer^ and it can only get a buffer at fork level (shared 
system tables must be altered to obtain a buffer). In 
addition to getting a buffer, the fork level terminal 
processing code must check for a rare race condition. 

After the arrival of the ControNC (or a npn Control*C 
character if tHe terminal is not attached) and between the 
time the fork is executed and control is regained in the 
oriven it is possible that the device may have returned to 
the busy state. This is because we may have Just unbusied 
the device for a ^previous request when the input interrupt 
occurredi The interrupt code finds the device free and 
executes a fork, But before control is regained at fork 
level, execution is continued in the driver for the previous 



PAGE a3 



request. The driver Jumps to the initiator entry to 
propagate its execution and tHus mav find another waiting I/O 
request which it will begin processing since the device is 
freet Thus the fork routine fr^ust recheck the state of the 
device. If it is busy the input is ignored and the driver 
returns (exits) frort fork level. Else an attempt is made to 
obtain a buffer for the unsolicited input, 

[Buffer Acquisition) 

If the buffer acquisition attempt is unsuccessful, the driver 
ignores the inout and exits. 

If a buffer is obtained, the driver sets up to start an 
unsolicited input request by initialifing various pointers 
and setting the status of the controller and unit to busy. 

If the initial input character was Control-C, then 

MCR> 

is echoed to signify an explicit request to input to MCR, 

Else the input character is stored in the buffer and 
echoed on the initiating terminal. 

The driver returns (exits) from fork level, 

[Character processing] 

Once the terminal driver has determined that input coming 
from an operator terminal is destined for MCR, it will 
transfer subsequent characters into the buffer acquired in 
Step 5, It also echoes the incoming characters. The 
acceptance of input will cease ifi 

a, "The buffer is filled (the buffer has room for 80 
characters) but the maximum accepted depends on the 
devi eet 

72 for KSR 

72 FOR VT05B 

80 for LA308 

80 for LA30S 

b. An end of line character is entered. The valid end of 
1 i ne characters arei 
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Cappiage Retupn 

ALT-Mode (codes 33, 175, and 176) 

7, Clnteppupt frowi a charactep echo] 

Is the device in input mode? If no go get anothep chapactep 

fpoff! the usep output buffep and echo it. If the device is in 

input fnode» is end«of-line set? If no pe-enable the kevboapd 

inteppupt and exit fpom the inteppuot. If end»of-Hne is 
detected, then foPk, 

8, CEnd*of "1 i ne ppoceasing * fopk TeveU 

Was the input solicited op unsolicited? Fop unsolicited 
input, deposit the UCB addpess and the tepwinating chapactep 
into the input buffep and link the buffep into MCR's input 
aueue, then pequest mcr to Pun, The dpivep itself cleaps 
contpol and unit busy and petupns to its initiatop entpy 
poi nt , 

Fop solicited input I/O Done will be called, Fipst, the 
nu^bep of characteps enteped is detepmined and the buffeped 
input is moved to the soliciting task's input buffep. The 
driver input buffer is peleased and I/O Done is called with 
the second I/O status word eaual to the number of bytes 
entered. The left byte of the first I/O status word is set 
eaual to the terminating character and the right byte to +!• 
The dPiver then Jumps to the initiator entpy point to 
propagate its execution. 



3, a, 3 MCR Operation 

After the reauett of MCR by the driven the file system is swapped out 
and MCR is swapped in. Control is passed to the MCR root segment 
which calls the Dispatcher (DSPTCH) overlay. DSPTCH, vie a privileged 
subroutine (SSWSTK), switches to system state. The call to this 
routine includes a parameter which is the address where the caller 
wants to return when it switches back to task state. The state 
switching routine performs the switch and resumes processing in the 
caller immediately following the call. When SSWSTK is called, it sets 
up an interrupt entry to the system. Interrupts are locked out while 
it pushes the passed return address and the PS on the stack, SSWSTK 
then calls interrupt save (SINTSV), On return from inteppupt save R3, 
R2, Rl, R0 aPe pushed onto the stack and now the stack state simulates 
that of an EMTt SSWSTK now calls the caller who resumes execution one 
instpuction past the call. When the calling poutine finishes, it 
petupns, which takes it back to SSWSTK, SSWSTK Jumos to Oipective 
Sxit which pedispatches the ppocessop. The effect of this is to 
resume the caller in task state at the passed retupn addPess. 
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M£R now proceeds at foHowsi 

I, [Request an unsoHcUed Inout queue entpyl 

The Disoatchep cells the Queue Removal routine CSQRMVF), 
SQRMVF will attempt to remove a buffer and deliver It to the 
Dispatchert If no buffer Is available Ccarry set return from 
SQRMVF) the Dispatcher exits. The buffer Is formatted as 
shown In Figure 3*6t 



<»»««WORD«««><«««*wORD»»i>><»-»UP TO et^ BYTES-»-> 



I LINK TO I UCB OF I COMMAND INPUT I 

i NEXT BUFFERl INPUT OEV i I 



Figure 3-6 Input Buffer 



The queue empty condition will never occur on an Initial call 
to MCR# since MCR Is not requested unless something Is In the 
queue, MCR will remain resident until It Has processed all 
the entries In the unsolicited Input queue. 

Note that the Dispatcher, during buffer requisition, is 
operating at system leveli and all queue entries are done at 
fork levelt Thus. the buffer removal process Is linearized 
with buffer Item entry. 

If OSPTCH gets a buffer. It saves the buffer address In a 
memory location and does a return. This return takes DSPTCH 
back to task state where the processing of the buffer begins, 

2. [Process a [Buffer] 

On return to task state, the dispatcher scans through tHe 
buffer and 

compresses out redundant spaces and/or tabs 
converts an Escape character to a Carriage return 
truncates trailing spaces and/or tabs 

If no lint terminator Is found In the buffer, a CR Is 
Inserted as the 60th character. Finally the actual line 
terminator (either CR or ESC5 Is saved so It can be restored 
In the message If the message must be routed to a task other 
than MCR 1 tsel f , 

The dispatcher then converts the first three characters to 
RAD50 and begins to search two Internal tables for an MCR 
function with a matching name. 
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3, [Searching the function tables • Table descriptions! 

MCR has two function tablesf one for privlleqed commands^ and 
one for non»pr 1 v 1 1 eged commands. 

Privileged commands are those whose unrestricted use could 
cause privacy violation or system failures and they can only 
be executed from a privileged terminal. Privileged terminals 
are Identified by a bit In the UCB, These terminals are 
established at SYSGEN or by the SET command. 

Both tables contain a 5-word packet for each command In the 
class (privileged or non-privileged). The packet appears In 
Figure S-T. 



i RAD50 CMD NAME (3 CHARS) 



i INDEX INTO COMMAND OVERLAY 



I ADDRESS OF PARSER TABLE 



1 RAO50 COMMON OVERLAY NAME 



I INDEX INTO COMMON OVERLAY 



Figure 3-7 «• Function Table Entry 



The table Is designed with the assumption that a given mcr 
function would not reauire more than three overlays to carry 
out Its Intentt Thus* the table entries correspond to three 
overlay types! 

Command overlay* 

P9f99r overlay* and 

Common overlay. 

The use of these overlay types Is In general observed, but 
exceptions occur and they will be noted. 

Typically* any command that can be processed In a single 
overlay* and whose size Is such that It renulres all or 
nearly all of the max overlay size (600 wds) will be classed 
as a command overlay. 

Parsers for the commands are distinct entitles and are 
grouped Into overlaysa Generally* a given parser services 
more than one command but three parsers currently service all 
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the comffiands. The parser entry is a pointer to a parser 
table entry shown in Figure 3»8, 



I RA0565 PARSER NAME (3-CHARS) I 



I IMDEX INTO PARSER OVERLAY I 



Figure 3»8 • Parser Table Entry 



Since three parsers service all the commands it is more 
economical in storage space to point to the parser table 
rather than include the name and the index in the main 
function table. 

The index is used at the entry point into the parser where 
the parsing for a given command begins. This is required 
since a parser can, and generally does, contain parsers for 
more than one command. 

The common overlay is used when the processing for a command 
is small enough to make it practical to group more than one 
command into a single overlay. This grouping saves space 
since ten words are required by the Overlay Runtime System 
for each overlay in a tree structure. The Index serves the 
same purpose as the index in a parser overlay. 

Note that a command overlay also contains an index. The 
value of the command overlay index is generally zerot But to 
maintain the coherence of the table processing commonality, 
and to allow for flexibility, the index is included, 

[Look UP and start a function other than an MCR internal 
f unct i on] 

The dispatcher then looks in the Pfivileoed command ^able for 
a name which matches the first three characters in the input 
buffer. This table contains all the privileged MCR commandst 
These are noted in the commands listed in Section 3,4,1, 

Internally, privileged terminals are identified by a bit in 
the UCB, The bit is set at SY8GEN or from a privileged 
terminal using the SET MCR command. 

If the command is not found in the privileged command table, 
the non*pri vi 1 eged command table is searched. 

If the name is not in either table, then the dispatcher will 
prefix three periods to the three buffer characters and using 
these six characters will search the STD looking for a match 
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on the name. If <t does not find the name it will display an 
error message on the initiating terminal. If it finds the 
name, it will request the function to run, suoplying as an 
argument to the requested task the UCB address that was in 
the input buffer. The UCB address is inserted into the TCB 
of the requested task as its TI (terminal input) oseudo 
device. If the attempt to request the task fails an error 
message is displayed, the buffer is released and mcr exits. 
Having discovered a non-internal MCR function, MCR must 
prepare to pass the buffer, since the initiated task is going 
to issue a GET MCR COMMAND LINE directive. To pass the 
buffer MCR uses three words in System Common, These words 
arei 

1, The TCB address of the requested task} 

2, The address of the- command buffer, and 

3, The byte count of the number of input characters in 
the buffer, 

MCR fills these words, making synch ron i f i ng checks that they 
are free, since only one triplet exists for passing buffers 
to a requested task. Thus, until the buffer is emptied, 
other completed buffers in the queue will be waiting. 

Eventually (and this should be soon) the requested task will 
start running, and issue a GET MCR COMMAND LINE directive. 
The directive processing then tests for a match on the TCB 
address in SYSCM and the TCB address of the requesting task. 
If they match the buffer is passed to the task by copying it 
into the DPS of the directive. The directive status is set 
to the byte count, the buffer is released and the TCB address 
in the SYSCM triplet is cleared. The TCB address being zero 
is an indication to MCR that the triplet is free, 

3b, [Start an Internal MCR function] 

Once a name match has been found in the command table, the 
Dispatcher copies words 1, 2, a and 5 of the function table 
entry and both words of the parser table entry for this 
command into the MCR root segment. Now the Dispatcher scans 
the function table entry as followsi 

3c, IF 

A parser exists 

THEN 



Go to a 
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ELSE 

IF 

a command overlay exists 

THEN 

Go to 3d 

ELSE 

IF 

a common overlay exists 

THEN 

Go to 5 

ELSE 

Abort 

3dt Form overlay name^ construct reauired overlay information 
packets and enter the root at the point where overlay loading 
is performed, 

a, [Parser functions] 

The selected parser will parse the buffer and^ if the parse 
is successful, ^t will Jump back to the root to load the 
desired function. If the parse fails, the parser deposits an 
error number in the root and Jumps to the entry SERLD in the 
root which loads the error overlay. 

Ultimately the root will initiate another routine, either the 
error routine or the requested function, 

5, [Function routines] 

These routines may further check the input and find errors. 
If errors are found, the function sets up the error routine 
and Jumps to the root to load an error overlay. If it 
succeeds, the function will release the buffer and enter the 
root at the point where the root will reload the dispatcher, 

60 [Error Overlay] 

The error overlay contains all error messages and the code 
needed to format the error message from the error number 
deposited in the root by the MCR component discovering the 
error. 



PACE 50 



7, CFInal Exit] 

The dispatcher calls the queue routine to obtain another 

buffer* if one is found the cycle of name table scanning 

resumes (starting at steo 2D, If no buffers are waiting, mcR 
exits. 



3,5 Partitions 

The user area of RSX-llM is divided into partitions. In unmapped 
systems tasks are bound to a specific partition and must execute from 
that partition. In mapped systems tasks may be installed and 
subsequently executed in any partition provided the partition is large 
enough and sufficient checkpoint space is available in the task image, 

A partition always consists of at least a main partition! the main 
partition can be subdivided into as many as seven subpartitions. The 
execution of tasks within the main partition and its subpartitions is 
mutually exclusive. This means that if a task is executing in the 
main partition no tasks may be executing in any subpartition of the 
main partition, Cont rarywi ae# if a task is executing in a 
subpartition no task requiring the main partition may be executing. 
The subpartitions, however, can all execute in parallel. 

Subpartitions exist so as to make it possible to reclaim and subdivide 
large Partitions that service nonrealtime tasks like language 
t rans 1 ators. 

If a main partition task is fixed in memory then no other main 
partition or subpartition task may execute until the task is unfixed, 
A fixed subpartition task will exclude the execution of a main 
partition task and other tasks wanting to execute from the subject 
subpartition. Other subpartitions operate independently. 

An identical set of conditions apply to tasks that are not 
checkpoi nt abl e. 

The manipulation of a partition and its subpartitions becomes more 
intricate when the tasks occupying them are not fixed in memory and 
are checkpoi nt abl et Any number of tasks can be waiting for use of the 
partition or subpartition. Given that no tasks running out of a 
partition are fixed in mewory> and that all are also checkpoi ntabl e* 
the sole determiner of which queued tasks waiting for the Partition 
will run is priority. 

When a task is requested it is entered into the appropriate partition 
wait queue and a sequence is initiated to determine if the existence 
of this task in the partition wait queue will require checkpointing of 
-^he task currently occupying the Partition, If the task entering the 
w^\t queue is of higher priority then that of the current task, 
checkpointing will proceed. 
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Wh«n • task that Is not fixed in mernory exits, the partition, wait 
queue for the Partition being freed is examined for the highest 
priority task waiting for the partition, and when located this task is 
loaded and put into active co?«petition for processor resources. 

Before proceeding to the detailed algorithms used to service a 
partition the key concepts are Hsted belowj 

Kf A partition consists of a main partition and up to seven 
subpart i t i ons. 

* Execution between a main partition and its subpartitions is 
mutual 1 y exc 1 usi ve, 

* Execution among subpartitions may proceed in parallel, 

* Tasks fixed in memory or not checkpointable lock up the 
partition or subpartition from which they are executing, 

* Any number of tasks may be waiting for a partition, 

* Task access to a partition is based on priority. Tasks not 
fixed in memory or not checkpointable will be rolled out to 
make room for higher priority tasks waiting to occupy the 
part i t i on, 



3,5,1 Partition Control Data Structures 

The data strAJCturas which service the partition concepts outlined 
above are shown in Figure 3««9, 
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Figure 3*9 • PaptUlon Data Structure 



THe very cowpOfltlon of the structure provides Insight Into both the 
extent of the service and how Internally the service Is prooagated to 
the user level. 

A word Is maintained In system common (SPARHD) that oolnts to the 
first main Partition Control Block CPCB) In the system, Fpom this PCB 
are linked the PCB'.s for any subpartitions, defined for this main 
partition, AVI PCB's defining other partitions and subpartitions are 
similarly linked. The last PCB Is a subpartition PCB except In the 
case where there are no subpartitions of the subject main partition. 
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In this ease the main partition PC8 Hnks to the next fi^aln partition 
PCB. The data structure Is then reoeated until we run out of PCB's to 
link together. Notice that the TCB's of tasks waiting to occupy 
either the »fla1n partition or a subpartition are alwavs linked fro"n the 
main partition PCB, The TCB's are ordered by priority and each 
contain a pointer to the PCS of the partition for which they are 
wal t 1 ng. 

The scheduling of a partition Is done by the next task (SNXTSK) 
routine. It Is the function of SNXTSK to select the next task In the 
list of TCB*s linked frow the fT>a1n partition welt queue that Is to 
occupy the main partition or a subpartition of the main partition. 
Note that this process Is Independent of which task In the system will 
gain control of the CPU next. 

There are four specific events which can result In a change of control 
In a partition, 

1, Task exit of a nonflxed task, 

SNXTSK must now look for another task waiting for the 
part 1 1 1 on, 

2« The loader has completed bringing a task Into memory, 
A new task Is now ready to compete for the Processor, 

3, An Initiation type request occurs. 
This can bei 

a, A RUN command from a terminal • 

b, A RUN or REQUEST Executive directive. 

In this ease several checks must be made by SNXTSK, (we will 
discuss these checks shortly) 

4, The outstanding I/O count for a cheekpol nt abl e task waiting 
for swap out has gone to zero. 

The loader must checkpoint the task and then call $NXTSK to 
select the next task to occupy the partition. 

Given these preliminaries we can now examine the algorithms used to 
service partitions. 



3,5,2 Partition Algorithms 

1, (servicing Initiation requests] 
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Is the reauested task active or currently being fixed in 

memorv? If veSf return carry set. (The request is redundant 

since the task is either running or in process or being 
set»up to run). 

If the task is in memory, it is fixed in memory and a 

partition allocation pass is not required. The following 
task set up is performed. 

An initial stack is constructed that will cause the task 
to start executing at its transfer address. 

The task status word is set to active, 

A conditional schedule request is set that will force 
redi spatch i ng of the processor if the task just made 
action is of higher priority than the currently running 
task. 

If the task is not in memory, then it is entered by priority 
in the Partition Wait Queue and SNXTSK is executed. 

It should be noted that a task f i xed- i n-memory remains 
physically in control of memory even if the task exits, A 
task that is not f i xed^i n«memory is removed from memory at 
task exit thus freeing the memory in which it resides^ 

2, CSNXTSK • Select the next task to run in a partition] 

SNXTSK begins a scan of the main partition wait queue seeking 
to determine if the partition, for which a task is waiting, 
is free. Note that a given task is not necessarily the one 
most recently inserted into the partition wait queue. 
Examination of the partition data structure will reveal that 
all TCB's, both for main and subpartitions, are linked from 
the main partition wait queue, 

SNSTSK checks if the partition is free. No, resume ^scan, 
Vesf insert the TCB address into the PCB declaring ownership 
of the PCB, Set the busy flag in both the main and 
subpartition. Remove the TCB from the partition wait queues 
insert it into the loader queue, 

A TCB is always linked into the SJD. A given TC8 may also be 
linked into either the loader^oueue or the Partition wait 
queue. 

The loader is then reauested and SNXTSK tries to allocate 
another task within the partition. The allocation orocess 
continues until either all waiting tasks have been assigned 
to partitions or an allocation failure occurs. 
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3t CSNXTSK Checkpointing * Main partition reauests] 

whenever SNXTSK finds a task waiting for a main partition 
that is busy it must make a checkpoint decision. For a main 
partition request* it proceeds as followsi 

3a, Is the task waiting for the main partition of sufficient 
priority to pre-empt the task currently occupying the main 
partition or a subpartition? no exit* the partition cannot be 
allocated to the waiting task, 

3b, Is the task occupying the partition in any of the following 
states? 

Not checkpointable 

Fixed in Memory 

Being Fixed in Memory 

If yes, exit the partition cannot be allocated to the waiting 
task, No# go to 3a and check the next subpartition. 
Eventually* either every subpartition is found to be 
checkpointable* or the main partition cannot be freed and 
SNXTSK exits, 

3c, [Checkpointing subpartitions] 

Once SNXTSK determines the main partition can be made 
available by checkpointing the tasks in the subpartitions it 
starts the checkpointing process as followsi 

Is the I/O count for the task occupying subpartition x0, No* 
go to 3d, Yes* execute the checkpoint initiation routine. 

Move the TCB occupying this partition into the loader aueue* 
set a bit establishing the task is checkpoi nted* and reauest 
the loader. No further action on this subpartition is taken 
until the loader recalls SNXTSK after the checkpointing 
process is completed, 

3d, Set a bit which indicates the task is to be checkpointed when 
its I/O count reaches 0, (This bit is tested by I/O Done* 
and if set* I/O Done calls the checkpoint initiation routine 
in 3c above), 

a, CSNXTSK checkpointing • Subpartition reauests] 

If a subpartition Is requested the essentials of the 
algorithm in 3 above is followed* but only the requested 
subpartition need be checked. 
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5tep» complete the description of partition management. But since 

the loader Is Intimately Involved with the algorlthrrs, It will be 
described In this section. 



3,5,3 The Loader 

The loader, which Is a resident RSX»llM system taski has three 
f unct 1 ons I 

1, Loading new tasks (Initial reading of disk 1mage)i 

2, Checkpointing tasks (writing task checkpoint Image to disk), 
and 

3, Resuming checkoointed task (reading task checkpoint image 
back from disk). 

The loader has a single objective! to empty the aueue of tasks waiting 
for its attention. The queue is serviced FIFO and 2 bits in the task 
status word# the checkpoint bit and the out of memory b1t# determine 
the loader action on an entry, 

CKPT on 

OUT OF MEM on 

The task is read back into memory from its checkpoint areat 
CKPT on 

OUT OF MEM off 

The task Is written from memory into its checkpoint area, 

CKPT off 

OUT OF MEM on 

The task is read Into memory from its load image, 

CKPT off 

OUT OF MEM off 

This combination is illegal. 

When tHe loader removes the next entry from Its queue, it assumes 
memory Is available if tHe task is to be readj after the loader writes 
a task into Its checkpoint area Release Partition is called which In 
turn calls, SNXTSK to select the next task that will occupy the 
part 1 1 1 on. 

On reading a task Into memorvi tHe loaderl 

1, Marks it In memory (1,e, clears OUT OF MEM), and 

2, Builds a Initial stack (on initial reads only) 
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Tke markinq of the task ir> memory has the effect of gnblock^i^g the the 
task so It can compete for system resources. As soon as a task Is 
requested It is consHered initiated. It will not compete for system 
resources however, until the loader marks it in memory. After 
completing the service for a queue entry the loader looks for more 
work, and when the queue is empty, it exits. 

Though the loader and SNXTSK call each other they are almost totally 
ignorant of each others function. The call from the loader to SNXTSK 
is such that SNXTSK can't distinguish it from other events that 
trigger SNXTSK, And, the loader makes very few decisions as evidensed 
by the fact that the description of its algorithm is best presented in 
narrative form. 
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^,0 FAULT ISOLATION - SOME GENERAL HINTS 



4,1 Introduction 

Though RSX^llM is a real time, mul t i pf^ogrammi ng system, it has, in the 
real memory version, no "brickwall" protection. The basic machine 
configuration which RSX-llM supports, has only a single program state, 
and no memory protection. The lack of these features simoly mean that 
the user state tasks can fault such that the system itself faults. In 
these circumstances, it becomes extremely important to develop the 
skills and discipline needed to rapidly isolate the source of a system 
failure. This section is a first attempt at recording the experience 
gained thus far in isolating software faults that occur in RSX*11M, 
Ultimately this section should evolve into a handbook for field 
software specialists. To reach this much needed state, it will 
require inputs and suggestion from all members, of the RSX-UM team. 



U,2 Fault Classifications 

Three culprits can be identified when the system faultst 

U A user state task has faulted such that it causes the system 
to faultj 

2, The RSX-UM system software itself has faulted, or 

3, The host hardware has faulted. 

The immediate action on the part of the Programmer subject to one of 
these errors is to determine which of these three cases is the source 
of the fault. Our prime concern will be the procedures which may help 
the programmer uncover the fault source. The repair of the fault 
itself is assumed to be the programmers responsibility. 

Faults manifest themselves in roughly three wavs (and they are listed 
here in order of increasing difficulty of isolation) 

U The system displays the CRASH pr.into.ut and halts. The CRaSh 
printout is discussed in Section x,x, 

2, The system halts but displays nothing, 

3, The system is in an unintended looPt 



-4.3 Immediate Servicing 
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.^X-UM can be built to contain reaident craah reporting and Panic 
dump routinea^ and our commenta aasu^e aucH a ayatem, (it aHould be 
noted that the miniwa) ayatem will not have apace for tHeae routineatJ 

The immediate aim# regardleaa of the fault man i f eat at i on^ is to 
initiate the craah reporting and panic dump routinea. 



4.3.1 Caae 1 - The Syatem Haa Diaplayed the Craah Printout 

In thia caae, all the baaic information deacribing the atate of the 
ayatem haa been displayed. We will pick up the actual Craah printout 
after we have deacribed how to invoke Panic Dump for caaea 2 and 3, 

4.3.2 Caae 2 - The Syatem Haa Halted • No Information Diaplayed 

Before taking any action preaerve the current PS and PC (i,e, examine 
and record). The procedure dependa on the particular POP^^ll 
proceaaor. For all proceaaorai the PC ia diaplayed in the addreaa 
regiater. The PC can alao be obtained aa followaj 

For an 11/45 

1, Enter a 7 in the conaole Switch Register 

2, Oepreaa load Addreaa 

3, Depreaa Regiater Examine 

u. The PC is diaplayed in the data lighta. Record the PC, 
For an U/40 or U/10 

1, Enter 777707 in the conaole awitch regiater 

2, Oepreaa Load Addreaa 

3, Oepreaa Examine 

a. The PC ia diaplayed in the data lighta. Record the PC, 

Now obtain the PS^ the procedure for which, ia identical in all 
ayat ema , 

1, Enter 777776 in the conaole awitch regiater 

2, Oepresa Load Addreaa 

3, Oepreaa Examine 
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a* The PS Is displayed in the data lights, Record the PS, 

Next Invoke the Panic Dump routine by entering a0(f!) in the switch 
register# Depressing Load Address, and then Start, 

aace) is the address of a JMP to the Panic Dump Routine in any RSX-UM 
svstefn. 

The Panic Dump saves R0*R6 and then halts awaiting dump limits to be 
entered via the console switch register. The PS is cleared when START 
is depressed, and the original PC is destroyed. Thus the importance 
of recording these vital pieces of debugging information before 
initiating the Panic Dump, 

Dumps of selected blocks of memory may be obtained using the following 
procedure t 

1 " Enter the low dump limit in the console switch register and 

depress continue. The processor will immediatelv halt again, 

2 • Enter the high dump limit in the console switch register and 

depress continue. The dump will begin on the device whose 

CSR address is D$$BUG (usually 177514 which is the line 

printer). At the end of the dump the processor will again 
halt awaiting the input of another set of dump limits. 

To reach the same status arrived at with crash reporting in 
Case X above, enter the dump limits 0"523(8D when the panic 
dump first halts. This will dump the system stack and the 
registers. 



4.3,3 Case 3 • System Is In An Unintended Loop 
Proceed as foil owsi 

Halt the processor 

Record PC, and PS as in 4,3,2 above. 

After recording the PS and pC# the programmer may want to steo through 
a number of instructions in an attempt to locate the loop. 

After the attempt to locate the loop transfer to the panic dump 
routine as in Case 2, 

This brings us to an equivalent status for the three fault situations. 



4.4 Other Pertinent Fault Isolation Data 
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Before proceeding with the task of locating the fault» the programmer 
Is strongly advised to dumo system common (SYSC^)» He can accomplish 
this by looking for the file SY8CM In the Executive load map listing 
and entering the appropriate limits to the Panic Dump Routlnet SYSCM 
contains a number of critical pointers ana llstheads. 

In addition the programmer should dump the dynamic storage pool and 
the device tables. The dynamic storage region Is the module IniTl. and 
the device tables are In SYSTB, 

The programmer now has! 

PS 

PC 

The Stack 
R0-R6 

The Dynamic Storage Region 
The Device Tables* and 
System Common 

This data Is a minimal requirement for effective fault Isolation, If 
an Individual programmer plans to consult with other group members on 
the source of a fault* he should do so only after he has collected 
this data, Eventuallyi we will require that all SPR's supply this 
1 nf ormat 1 on. 



4,5 Fault Tracing 

Three pointers In SYSCM are critical In fault tracing, 

SSTKDP • Stack Depth Indicator 

This data Item will Indicate which stack was being used at the 
time of the crash. As will be seen* this plays an Important role 
In determining the origin of a fault. The following values 
apply, 

fl » User (task state) stack 
or less « System stack 
STKTCB • Pointer To the current Task TCB 

This Is the TCB of the user level task In control of the CPU, 



PAGE 62 



SHEADR ^ Pointer To The Current Task Header, 

Locating the Header provides some other useful data. The first 
word in the header is the users stack pointer the last time it 
was saved. If the Stack Depth is f I then the user has managed to 
crash the system. In a system with brickwall protection (for 
eKamplei the mapped RSX-llM system), the user should not be able 
to crash the system, Even if the user stores in the Executive, 
the crash will not occur until the state is switched and then the 
system will crash. Such a fault may prove difficult to locate. 

If the user branches wild)y into the Exec it will terminate the 
user task, but the system will continue to function (possibly 
erroneously). Knowing the users stack pointer provides one more 
link in the chain which may lead to the resolution of the fault. 



4,5,1 Tracking Faults Following An Automatic Display Of The System 
State (Case 1) 

First examine the system stack pointer. Usually an Executive failure 
is the result of an SST type trap within the Executive (other than the 
speciaHzed use of the trap instruction). 

If an SST does occur within the Executive, then the origin to the call 
on the crash reporting routine will be in the SST service module, 
(The crash call it initiated by issuing an lOT at a stack depth of 
zero or less,) 

A call on crash also occurs in the Directive Dispatcher when an EMT 
was issued at a stack depth of zero or less# or a trap instruction was 
executed at a depth of less than zero. The stack structure in the 
case of an internal SST fault is as followsi 
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PS 
PC 
R5 
Ra 
R3 
R2 
Rl 
R0 

ZERO OR MORE SST PARAMETERS 
SST FAULT CODE 
NUMBER OF BYTES l<»-^-SP 



Figupt 4-1 



The PC points to the instruction following the one which caused the 
SST failure. The number of bytes Is the number of bytes that are 
normally transferee! to the user stack when the particular type of SST 
^ occurs. If the number Is then Just the PS and PC are transfered 
and there are no SST parameters. The definition of each fault code 
can be found In the file A80DF, 

If the failure Is detected In SDRDSP the stack Is the same as Figure 
a-l except the number of bytes# SST fault code# and SST parameters are 
not present. The crash report message# however* will Indicate the 
failure occurred In SDRDSP, 

There la one SST-type failure that will not have the stack structure 
of Figure and that Is stack underflow. To distinguish the two 

cases, determine where the crash actually occurred. If It occurred In 
SDRDSPf or was a normal SST crash, then Figure a-l Is the stack 
structure preserved. If It was a non-normal SST, then Figure 4*2 Is 
the preserved structure. 
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<— SP 



I 


PS 


I 


I 


PC 


i 



Figure a«2 



Non»norma1 SST failures occur when it Is not oossible to push 
Information on the stack without forcing another SST fault, when this 
occurSf a direct Jump to the crash reporting routine Is made rather 
than an lOT crash, The PS and PC on the stack are those of the actual 
cra8h# and the address printed out by the crash reporting routine Is 
the address of the fault rather than the address of the lOT that 
crashes the system, Note that the crash reporting routine removes the 
PC and PS of the lOT Instruction from the stack which In this case Is 
Incorrect, Thus the stack pointer will appear to be 4 greater than It 
really Is (1,e, as In figure 4»2), 

The programmer now has all the Information he needs to Isolate the 
cause of the failure. From this point on he must rely on his own 
experience and knowledge of the Interaction between his program and 
the services provided by the Executive, 



4,5,2 Tracking Faults When The Processor Halts without Providing A 
Fault Display 

Tracking starts with an examination of $STKOP# $TKTCB» and SHEADR. 
THe difficulty In tracking failures In this case Is that the system 
stack Is not directly associated with the cause of a failure. 

By examining $STKOP# one can determine the system state at the time of 
failure. If It was In user state, the next steo Is to examine the 
users stack. The examination process focuses on scanning the stack 
for addresses which may turn out to be subroutine links which will 
ultimately lead to a thread of events Isolating the faulty This Is 
essentially the saw© alff In looking at the System stack If SSTKDP Is 
zero or less. 

Frequently a fault will occur such that the 8P points to Top of Stack 
CT0S)>4, This results from Issuing an RTI when the top two Items on 
the stack are datai this will result In a wild branch, then, most 
probably, a halt. Figure UmZ shows a case, where two data Items are 
on the stack when the programmer executes an RTI. 

TOS points to a word containing 40100, Suppose that location 40ie»2 
<?onta1ns a halt. This Indicates that the original SP was four bytes 
below the final SP and fault tracing should begin from the previous 

SP, 
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i<--SP 


I 


51 


J 


acii00i<«-sp 



Figure a»3 



a,5,3 Tracking Faults when An Un*<ntended Loop Has Occurred. 

After Halting the processor, we are roughly in the same state as the 
preceeding section. Some specific suggestions are to check for a 
stack overflow looPt Patterns of data successively duplicated on the 
stack indicated a stack looping failure. 

The console lights may also indicate the origin of a problem, A 
tight, glimmering pattern may indicate hardware, while a blinking, 
more elongated, yet repetitive pattern may indicate software. 
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9,C5 DATA STRUCTURES 



5,1 PirtUion Control Rlock (PCB) 



P.LNK 
P.NAM 

P. sub' 

P.MAIN 
P.REL 
P. SIZE 
P.WAIT 

P.BUSY 

P.TCB 

P.STAT 

P.PDR 

P.HDR 



PCB LINK WORD 



PARTITION NAME 
(RADIX 50) 



PNTR TO NXT SUB-PARTITION PCB 
POINTER TO MAIN PARTITION PCB 



PHYSICAL ADDRESS 
SIZE OF PARTITION IN BYTES 



PARTITION WAIT QUEUE 
LISTHEAD 



PARTITION BUSY FLAGS 
TCB ADDRESS OF OWNER 



PAR STATUS I# APR'S TO LOAD 

CONTENTS OF LAST PDR 
ADOR OF HDR IN MAPPED SYSTEM 




2 
a 

6 

10 
12 

la 

16 
20 
22 

2a 

26 
30 
32 



- MAPPED 

I SYSTEM 
I ONLY 
I 



5,l.l Partition Control Block Details 



P.LNK 



Dascri pt i oni 

Pointer to next partition. The PCB'a are linked in physical 
address order, highest to lowest. If a main partition has 

subpartitions these are linked in the PCB chain off the '"ain 

partition in highest to lowest address order. The last 

subpartition of a main partition will either end the PCB 

chain or link to the next main partition, A main partition 

with no subpartitions either links to the next main partition 
or ends the chain. 



PAGE 67 



InitiaHzation/Acceasi 

P.NAM 

DescPi Dt i oni 

Radix 50 partition name, 
Initialization/Accesai 

P.SUB 

DeacPiPtioni 

Points the next subpoption, Stpuctuped and used analgously 
to P.LNK when manipglatinq a chain of suboaptition PCB's, 

Initialiiati on/Access i 

P.MAIN 

Descpi pt ioni 

Backpointep fpom a subpaptition to its papent main paptitiont 
Ini t i ali zat i on/ Access t 

P.REL 

Descpiptionj 

Paptition base pelocation bias. In a mapped system P.REL is 
the bias9 in an unmapped system, P.REL is the actual 
paptition address, 

Ini t i al i zat i on/ Access i 

P,HDR (unmapped system only) 

Oescpiptionj 

Task Headep pointep, 

P. SIZE 

Oescpiptioni 

Size of partition in bytes, 

Ini t i ali zat i on/ Ac c east 
P.WAIT 
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Descr^ptioni 

A pointer to a Hst of tasKs awaiting the use of the 
partition. The Hst is ordered by priority and is searched 
to determine which task should be in control of the 
partition. 

Initial iiation/Accessi 

P,BUSY 

Oeac r i ot i on I 

A two byte field. The first byte# the busy status, is the 
inclusive or of the state for the main partition and all its 
subpartitions. The second byte, the busy mask, contains a 
busy(l) not busy(0) settinq for the main partition and its 
seven subpartitions. 

Initial ixation/Accessi 

Under complete control of the set command processor, 

P.TCB 

Description! 

TCB address of partition's owner 
Initial ization/Accessi 
P.STAT 

Description! 



The status bits have the following meaning! 



Bit 



Symbol i c 



Meani ng 



0»2 



PS, APR 



Starting APR number for non-PIC libraries 



3 

a 
5 

6 

7 



Reserved 
Reserved 
Reserved 
PS, PIC 



PS, COM 



Library is Position Independent IcYes 
Partition is a COMMON/LIBRARY partition 



Initialiiation/Accessi 



P.NAPR 



Desc r i pt i on I 



Number of APR's to load, 
InitiaHzatlon/Accessi 
PtPOR (rflaDped systems only) 
Oescri pt \ om 

Contents of the last PDR, 
InitlaHzation/Accessi 
P.HDR (mapped systems only) 
Desc p i pt i on I 

Address of tHe Task Header. 
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5,2 Task Control Block 



T.LNK I UTILITY LIMK WORD i 

T.PRI 

T.IOC i I/O CNT 1 PRIORITY I 2 

T.TCB I ADDRESS OF THIS TCB I a 

T.NAM I TASK NAME J 6 

IN 

i RADIX50 i 10 

T.RCVL I i 12 

RECEIVE LI8THEAD 

1 i la 

T.ASTL I I 16 

AST LISTHEAD 

I i 20 

T.EFLG I TASK LOCAL i 22 

EVENT FLAGS 1-32 

i i 2a 

T.UCB I UCB ADDR OR REQUEST TERMINAI I 26 

T,TC8L I TASK LIST THREAD WORD I 30 

T.STAT I TASK STATUS WORD I 32 

T.LBN » LOGICAL BLOCK JTSK STATUS EtJ I 34 

1 NUMBER OF TASK LOAD IMAGE I 36. 

T.LDV I UCB ADDRESS OF LOAD DEVICE i 40 

T.PCB i PCB ADDRESS OF LOAD PARTITION i 42 



TASK STATUS WORD BIT DEFINITIONS 



BIT 


SYMBOLIC 







TS.CKD 


C>seckDO<nt Disable 


l»ves 


I 


TS.CKR 


CheckDoint Request 


layes 


2 


TS.CKP 


Checkpol nted 


l»ye8 


3 


TS.OUT 


Out of core 


Isyes 


a 


TS.FXO 


Fixed In memory 


l»yes 


5 


TS.BFX 


Task Being Fixed 


layes 


6 


TS.CHK 


Task checkpointable 


08yes 


7 


TS.AST 


AST In progress 


layes 


6 


TS, ACP 


Ancillary control processor 


layes 


9 


Reserved 





10 Reserved 



11 


TS.REM 


Remove task at exit 


layes 


12 


TS.MSG 


Abort Message being cutout 


layes 


13 


TS.OST 


AST recognition disabled 


layes 


la 


TS.RDN 


I/O rundown In orogpess 


layes 


15 


TS.EXE 


Task In execution 


0syes 


TASK STATUS 


EXTENSION BYTE BIT DEFINITIONS 




BIT 


SYMBOLIC 









TS.WFR 


Task In WAITFOR 


layes 


I 


TS.SPN 


Task suspended 


layes 


2 


none 


Saved TS.WFR on AST 




3 


none 


Saved TS.SPN on AST 




a 


TS.MCR 


Task requested as mcr function 


layes 


5 


TS, ABO 


Task marked for abort 


layes 


6 


TS.PRV 


Task Is privl leged 


layes 


7 


TS.HLT 


Task being halted 


1 ayes 



5,5 Task Header 
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H.CSP 

H.HOLN 

H.PCBT 



H.PCBC 



H.DSW 

H.FCS 

H.FORT 

H.OVLY 

H.RSVO 

H.EFLM 



CURRENT SP 



HEADER LENGTH IN BYTES 
TASK PCB ADDRESS 



LOW VIRTUAL ADDRESS 
HIGH VIRTUAL ADDRESS 



ACCESS i USER PDR 
COMMON PCB ADDRESS I 



LOW VIRTUAL ADDRESS 
HIGH VIRTUAL ADDRESS 



ACCESS 1 USER PDR 
COMMON PCB ADDRESS 2 



LOW VIRTUAL ADDRESS 
HIGH VIRTUAL ADDRESS 



ACCESS I USER PDR 
COMMON PCB ADDRESS 3 



LOW VIRTUAL ADDRESS 
HIGH VIRTUAL ADDRESS 



ACCESS I USER PDR 
(3 END OF PCB'S (SENTINEL) 



SAVE AREA FOR TASK DSW 
FCS IMPURE POINTER 



FORTRAN IMPURE POINTER 
OVERLAY IMPURE POINTER 



RESERVED 
EVENT FLAG MASK WORDS 



2 

a 

b 

10 
12 

la 

16 
20 
22 

2a 

26 
30 
32 
34 
36 
40 
42 
44 
46 
50 
52 
54 
56 
60 
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FOR EVENT FLAGS 


I 62 




1-64 


I 6a 


1 1 66 


H.CUIC 1 


CURRENT TASK UIC 


I 70 


H.DUIC i 


DEFAULT TASK UIC 


I 72 


H,IPS I 


INITIAL PS WORD 


I 74 


H.IPC 1 


INITIAL PC WORD 


I 76 


H, ISP j 


INITIAL SP 


I 100 


H,OOVA 1 


ODT SST VECTOR ADDRESS 


I 102 


H.ODVL 1 


ODT SST VECTOR LENGTH 


I 104 


H,TKVA 1 


TASK SST VECTOR ADDRESS 


I 106 


H.TKVL 1 


TASK SST VECTOR LENGTH 


I 110 


H.PFVA 1 


POWER FAIL AST 


i 112 


H,FPVA 1 


I FLOATING PNT EXCPN AST 


I lia 


H.FPSA 1 


I FP OR EAE REG SAVE AREA ADOR 


I 116 




I REVERSED 


I 120 




i RESERVED 


I 122 




I RESERVED 


I 124 


I.GARO j 


I ADDRESS OF STACK GUARD WORD 


I 126 


l,NLUN 


I COUNT OF LOGICAL UNITS 


I 130 


I.LUN 


I START OF LOGICAL UNITS 


I 132 



EACH LUN CONSISTS OF 
TWO WORDS, UP TO 255 
LUNS CAN BE ACCOMODATED 



LAST LUN ENTRY 



i 

....••FLOATING POINT OR EAE 
i SAVE AREA 

(3 OR 25 WORDS) — 

/ 
/ 
/ 
i 



i 


CURRENT 


PS I 


I 


CURRENT 


PC I 


I 


CURRENT 


R5 I 


I 


CURRENT 


Ra I 


I 


CURRENT 


R3 I 


I 


CURRENT 


R2 I 


I 


CURRENT 


Rl i 


I 


CURRENT 


R0 I 


I 


STACK GUARD WORD I 
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CHAPTER 3 



5,4 I/O DATA STRUCTURES 

Of all the centre) blecks H the I/O data structupCf enly four are of 
direct concern te a dr^veri 

1, The I/O Packet! 

2, The OCBf 

3, The UCB, and 
a, The 8CB, 

Although the data structurea contain an abundance of data pertaining 
to Input/output operational drivers per se are Involved only with a 
subset of this data. Most of the data which Is used by a driver is 
supplied In the data structure source, and Is not referenced during 
driver execution. 



5. a. I The I/O Packet 

Figure 3"l Is a layout of the 18-word I/O Packet which Is constructed 
and placed In the driver I/O queue by QIO directive processing and 
subseauently delivered to the driver by a call to SGTPKT, Figure 3-2 
Is the OPS from which the I/O Packet Is generated, ^ 7 



I 
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I. INK 
I. EFN 
I.PRI 

I.TCB 

I.LN2 

I.UCB 

I.FCN 

I.IOSB 



I, AST 
I.PRM 



LINK TO NEXT I/O PACKET 



EFN I PRI 

TCB ADDRESS OF REQUESTER 



ADDRESS OF SECOND LUT WORD 
ADDRESS OF REDIRECT UCB 



FUNCTION CODE I MODIFIER 
VIRTUAL ADDR OF I/O STATUS BLK 



RELOCATION BIAS OF I08B 
REAL ADDRESS OF lOSB 
VIRTUAL ADDR OF AST SERVICE RTN 



DEVICE 
PARAMETERS 



7^ 
2 

a 

6 

10 
12 
la 

20 
22 



Figure S^l I/O Packet Format 
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5,«,l.l I/O Packet Oetans - The I/O Packet i% built dynaffically bv 
QJO directive processing, Thus# no static fields exist with respect 
to a driver, I/O Packets are created dynamically and# therefore^ the 
first parameter does not aooly. Fields are classified ast 

not referenced^ 
read-only* or 
read/wr i te, 

I, INK 

Description! 

Links I/O Packets queued for a driver, A zero ends the 
chain. The listhead is in the SCB (S.LHO), 

Initial Ization/Accessj 

not referenced, 

I.PRI 

Descriotion: 

Priority copied from the TCB of the reouesting task, 
Initializati on/Accessi 
not referenced, 

I,EFN 

Desc r 1 pt 1 on I 

Contains the event flag number as cooled by QIO directive 
processing from the requester's OPB, 

Initial izati on/ Access i 

not referenced, 

I. TCB 

Description! 

TCB address of the requesting task, 
Initializati on/Accessi 

not referenced. 



I.LN2 
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Oesc r < Dt < oni 

Contains the address of the second word of the LUT entry <n 
the task header to which the I/O reauest was directed. For 
open files on file structured devices^ this word contains the 
address of the window block, otherwise it is zero, 

Initialization/Accessi 

not referenced, 

I.UCB 

Desc r i pt i on i 

Contains the address of the Redirect UCB if the starting UCB 
has been subject to a Redirect MCR command, 

Initialization/Accessi 

not referenced, 

I.FCN 

Oescript ioni 

Contains the function code (see table 3»1) for the I/O 
request , 

Initialization/Accessi 

read»on 1 y, 

I.IOSB 

Description! 

ItlOSB contains the virtual address of the I/O Status block 
(lOSB) if one is specified or zero if nott 

I,I0SB+2 and I,IOSB+« contain the address doubleword for the 
lOSB (see Appendix A for a detailed description of the 
•ddress doubleword)^ On an unmapped system, the first word 
is zero, the second word is the real address of the lOSB, 

In a mapped system, the first word contains the relocation 
bias of the lOSBf the bias isf in effects the 32«word block 
number in which the lOSB starts. This block number is 
derived by viewing available real memory as a collection of 
32*word blocks numbered consecutively, starting with 0, 
Thus, if the I03B starts at Physical location 3210(8), its 
block number is 32(8). 
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The second word is foPTiatted as followsj 

Bits 0»5 Di sol acefnent In Block CDIB) 
Bits 6*12 AH zeros 
Bits 13-15 6 

The displacement in block is the offset from the block base* 
In the above example where the lOSB started at 3210(6), the 
DIB is equal to 10C8), 

The value 6 in bits 13-15 is constant. It is used to cause 
an address reference through Kernel Page Address Register 6, 
Again, see Appendix A for details. 

The deferral of a discussion of the address doubleword to an 
appendix reflects the fact that a writer of a conventional 
driver has almost no need to conce^'n himself with the 
contents or format of the address doubleword, Its 
construction and subsequent manipulation are normally 
external to the driver? subroutines are provided as Executive 
services for programmed I/O to render the manipulations of 
I/O transfers transparent to the driver itself, 

Initialization/Accessi 

not referenced, 

I. AST 

Oesc r i pt i on i 

Contains the virtual address of the AST service routine to be 
executed at I/O completion. If no address is specified, the 
field contains zero, 

Initialization/Accesst 

not referenced, 

Descri Pt i oni 

Device dependent parameters copied from the OPB, 
Initialization/Aecessi 



not initialized, read-only. 
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The QIO D 



rectlve Paraweter Block (OPB) Is constructed as foHowat 





1 LENGTH 


I 


Die 


» 


i FUNCT CODE 


i 


MODIFIER 


I 


I RESERVED 


I 


lUN 


I 


I PRIORITY 


I 


EFN 


I 


I I/O STATUS 


BLOCK 


ADDRESS 


I 


i AST 


ADDRESS 


I 




DEVICE 




i 



DEPENDENT 
PARAMETERS 



1 16 
I 20 

1 2a 

I 26 



Figure 3*2 QIO DPB 
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The parameters have the following interpretation. 
Length Crequired)i 

The length of OPB, which for the RSX*11M QIO directive, is always 
fixed at twelve words. 

Die (required)j 

Directive Identification Code, For the QIO directive, the value 
i 8 a 1 • 

Function Code (required)t 

The code of the requested I/O function (0 thru 31,5, 
Modi f ier J 

Device dependent ffodifier bits, 
Reservedi 

Reserved byte and must not be used, 
tUN (required) I 

Logical Unit Number, 
P r i r i t"v I 

Request priority. Ignored by RSX-UM, but space must 
be allocated for RSX-UD compatibility, 

EFN (oPtionaDi 

Event flag number, 

I/O Status Block Address Coptional)t 

This word contains a pointer to the I/O status block which is a 
2»word device dependent I/O completion data packet formatted ast 

Byte 

I/O status byte. 

Byte I 

Augmented data supplied by the driver 
Bytes 2 and 3 
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The contents of these bytes depend on the value of byte P5, 

If byte s l# then these bytes usuaUy contain the 

processed byte count. If byte does not eaual zeroi then 
the contents ape device dependent, 

AST Address (optional)i 

Address of an AST Service Routine, 

Device Dependent Perametersi 

Up to six parameters specific to the device and I/O function to 
be performed. Typically for data transfer functions these arei 

Buffer address 

Byte count 

Carriage control type 
Logical block number 



Any optional parameters that are not specified should be filled with 
zeros. 
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S,a,2 Device Control Block 

The device control block CDCB) defines generic infopwetion about a 
device type and the lowest and highest unit numbers. There is at 
least one DCB for each device type in a system. For example, if there 
are teletypes in a systemi then there is at least one DCB with the 
device name 'TT', If part of the teletypes were interfaced via 
DLll»A»8 and the remainder via a DHU, then there would be two DCB's. 
One for all OLU-A interfaced teletypes and one for all DHU 
interfaced teletypes. 



LINK TO NEXT DCB (0sLASTD I 



LINK TO FIRST UCB 
GENERIC DEVICE NAME 



1 2 



HIGHEST UNIT #IL0WEST UNIT « I 6 
LENGTH OF UCB I 10 



ADOR OF DRIVER DISPATCH TABLE i 12 
LEGAL FCN MSK BITS 0-15, I la 



CONTROL FCN MSK BITS 0-15, I 16 
NO-OP'ED FCN MSK BITS 0-15. I 20 



ACP FCN MSK BITS 0-15, I 2a 

LEGAL FCN MSK BITS 16.-32, I 26 



CONTROL FCN MSK BITS 16,-32. I 30 
NO-OP'ED FCN MSK BITS 16.-32. I 32 
ACP FCN MSK BITS 16.-32. I 3a 



Figure 3-3 Device Control Block 



5. a, 2,1 DCB Details 
D.LNK (Link to next DCB5* 



♦ Parent hesi led contents indicate value to be initialized in the data 
base source. 
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Desc ri Dt 1 oni 

Address Hnk to the next DCB, A zero <n this field indicates 
the last DCB in the chain. The driver writer links his OCB 
into the system DCB's via the global label $USRT8 on his 
first DCB. 

Initial iration/Accessi 

initialiied# not referenced, 

D,UCB (Pointer to First UCB5 

Descript ioni 

Address link to the first and possibly the only UCB 
associated with the DCB, All UCB'Si for a given DCB^ are in 
contiguous frewory locations and must all be the same length. 

Initial iiation/Accessi 

initializedi not referenced, 

D.NAM (ASCII Device Name) 

Oescri ot i oni 

Generic device name in ASCII by which device units are 
mnemonically referenced. 

Initial i zat i on/ Access i 

initialized^ not referenced. 

O.UNIT (Unit Number Range) 

Description! 

Unit number range for the device. This range covers those 
logical units available to the user for device assignment. 
Typically* the lowest number is zero and the highest is n»l, 
where n is the number of device-units described by tHe DCB, 

Ini tial i zat ion/Access I 

initialized! not referenced, 

D.UCBL (UCB Length) 

Descript ionj 

The UCB may have any length to meet the needs of the I/A| DCB 
must have the same length. 
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InltiaHiatlon/Accessi 

jnitiaHzedf not referenced, 
O.OSP (Dispatch Table Pointer) 
Oeac r i pt i on I 

Address of the driver dispatch table, 

iNhen the Executive wishes to enter the driver at any of the 
four entry points contained in the driver dispatch tab1e# it 
accesses D.DSPi locates the appropriate address in the table^ 
and calls the driver at that address, Thus» null addresses 
are not permitted. If the driver does not process a given 
function^ then it simply returns. The driver writer must 
provide a driver dispatch table in the driver source. The 
label on this table is of the form SnnTBL and must be a 
global label. The designation nn is the 2-character generic 
device name for the device, Thus# STTTBL is the global label 
on the driver dispatch table for the generic device name TT, 
This table is an ordered ^**word table containing the 
following entry pointsi 

I/O Initiatori 

Cancel I/Of 

Device Timeout^ and 

Power failure. 

When a driver is entered at one of these entry points^ entry 
conditions are as follewsi 

At Initiatori 

If UC.QUEal 

P5 B UCB address 

Rl s Address of the I/O Packet 

If UC.QUE«0 

R5 B UCB address 

Interrupts are allowed. 

At Cancel I/Oi 

R5 » UCB address 

Ra « SCB address 

R3 = Cont rol 1 er i ndex 

Rl a Address of TCB of current task 

R0 B Address of active I/O packet 
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Device interrupts are locked out. 

At Device Tlmeoutj 

s UCB address 
R4 8 SCB address 
R3 B Cont rol 1 er 1 ndex 

R0 « I/O status code lE.ONR (Device Not Ready) 

Device Interrupts are locked out. 

At Power Fal 1 urei 

R5 s UCB address 
R4 s SCB address 
R3 s Cont ro j 1 er 1 ndex 

Interrupts are allowed, 

Inl 1 1 a 1 1 lat 1 on/Access t 

Initialized^ not referenced, 

O.MSK (Function Masks) 

Descrlptloni 

There are eight words beginning at D,MSK which are of criti* 
cal Importance to the proper functioning of a device driver. 
The Executive uses these words to validate and dispatch the 
I/O request specified by a QIO directive. The description 
which follows applies only to non«-file structured devices* as 
directions for writing drivers for file structured devices 
(drivers which interface to FCP) are not Included in this 
manual. Four masks, 2-worcls per mask, are described by the 
bit configurations established by the driver writer for these 
words, 

1, Legal function mask} 

2, Control function maaki 

3, No*op'ed function mask, and 

4, ACP function mask. 

The QIO directive allows for 32 possible I/O functions. The 
wasksf as stated, are filters to determine validity and I/O 
requirements for the subject driver. 

The function value in the I/O request is filtered by the 
Executive through the four mask words, I/O function codes 
range from 0»31, if the function corresponds to a true 
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condition in a mask word, a bit is set in the mask in the 
position which numerically corresponds to the function code, 
Thus# if the function 5 is legal* then bit 5 in the Leqal 
Function *^%9k is set. 



The masks are laid out in memory in two ^i-word groups. Each 
^■word group covers 16 function codes. The first four words 
cover the function codes P)-15,# the second four words cover 
codes 16«31, Below is the exact layout used for the driver 
example in Chapter 5, 



.WORD 


140033 


,WORD 


30 


,WORD 


ia0000 


,WORO 





.WORD 


5 


,WORD 





.WORD 


I 


, WORD 


a 



fUEGAL FUNCTION MASk CODES 0-15. 
^CONTROL FUNCTION MASK CODES 0»15. 
fNO-OP'ED FUNCTION MASK COOES 0«15. 
>ACP FUNCTION MASK CODES 0-15, 
jLEGAL FUNCTION MASK CODES I6,«3l. 
ICONTROL FUNCTION MASK CODES 16,-31, 
|NO-OP'ED FUNCTION MASK CODES 16,-31, 
>ACP FUNCTION MASK CODES 16,-31, 



The mask words filter sequentially as followsi 



Legal Function Maski 

Legal function values Have the corresponding bit position in 
this word set to 1, Function codes that are not legal are 
rejected by QIO directive processing by returning lE.IFC in 
the I/O status block, provided an lOSB was specified. 

Control Function Maski 



If any device dependent data exists in the OPB# and this data 
does not require further checking by the QIO directive 
processor! the function is considered in the class <control 
function>t Such a function allows 010 directive processing 
to copy the DP8 device-dependent data directly into the I/O 
Packet • 



No-op'ed Function Maski 



A no-op function is any function that is considered 

successful as soon as it is issued. If the function is a 

no-oPr QIO directive processing immediately marks the request 
successful! no additional filtering occurs. 



ACP Function Maski 

If a function code is legal» but neither control nor no-op# 
then it is either an ACP function or a transfer function. If 
a function code may require intervention of an Ancillary 
Control Processor CACP)# the corresponding bit in the ACP 
function mask must be set. 
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In the specific case of read/wrUe virtual functions^ the 
corresponding mask bits may be set at the driver writer's 
option. If the corresponding mask bits for a read/write 
virtual function are set, QIO directive orocessing will 
recognize that a f i 1 e*o r i ent ed function is being reouested to 
a non-file structured device and convert the reauest to a 
read/write logical function. 

This conversion is particularly useful. Consider a 
read/write virtual function to a specific device: 

1, If the device is file structured and a file is open 
on the specified LUN, the block nurr^ber specified is 
converted from a virtual block number in the file to 
a logical block number on the medium and the request 
is queued to the driver as read/write logical, 

2« If the device is file structured and no file is open 
on the lun» then an error is returned and no further 
action is taken, 

3, If the device is not file structured then the request 
is simply transformed to read/write logical and 
queued to the driver, (Specified block number is 
unchanged) , 

Transfer Function Processing 

Finally, if the function is not an ACP function, then by 
default! it is a transfer function. All transfer functions 
cause the QIO directive processor to check the specified 
buffer for legality Cite,, is it within the address space of 
the requesting task), and proper alignment (i,e,, word or 
byte)i Also, the number of bytes being transfered is checked 
for proper modulus (i,et, noniero and a proper multiple)^ 

Ini t i al i zat i on/ Access i 

initialized, not referenced. 



Mask Word Creation 

The creation of the function mask words involves three stepsi 

U Establish the I/O functions available on the device for which 
driver support is to be provided, 

2, Check the standard RSX-llM function code values in table 3.1 
for equivalencies. Only function code is mandatory. 
Function codes 3 and a, if used, must have the RSX-llw system 
interpretation. It is suggested that functions having an 
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RSX-llM systeiT^ counterpart use tHe RSX-Um cocle# but this is 
not peauired except in the case where the device is to be 
used in conjunction with an ACP, From the supported ^unction 
1ist> the two legal function mask words can be built, 

3, Given the legal function mask# 

3a, The Control Function mask is built by askingj 

Does this function carry a standard buffer address and 
byte count in the first two device dependent parameter 
words? 

If it does not* then it either qualifies as a control 
function* or the driver itself must effect the checking and 
conversion of any addresses to the format required by the 
driver, (Buffer addresses in standard format are 
automatically converted to Address Doubleword format,) 

Control functions are, essentially, those whose OPB's do not 
contain buffer addresses or counts, 

3b, The No"Op Function Mask is created by deciding which legal 
functions are to be no-op'ed. Typically, for File Control 
Services CFCS) compatibility on non«file structured devices* 
the file aecess/deaceess functions are selected as legal 
functions even though no specific action is reouired to 
access or deaccest a non«file structured devicei thus, the 
access/deaccess functions are no-op'ed, 

3c, Finally, the ACP functions Write Virtual Block and Read 
Virtual Block may be included. Other ACP functions that 
wight be included fall into the non*convent i ona 1 driver 
classification and are beyond the scope of this document. 



3,1,2,2 I/O Function Codes • The filtering process which cascades 
through the function mask words in the OCB uses the function code byte 
supplied in the QIO directive DPB as the match value. Table 3-1 
contains the function values used for DEC-supplied driver's. 
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TABLE 3-1 
STANDARD I/O FUNCTION COOES 



FUNCTION EQUATED I/O 

VALUECS) SYMBOLIC FUNCTION 






lO.KIL 


CANCEL I/O 


1 


ID, WLB 


WRITE LOGICAL BLOCK 


2 


lO.RLB 


READ LOGICAL BLOCK 


3 


10, ATT 


ATTACH DEVICE 




lO.OET 


DETACH DEVICE 


5 




UNUSED 


6 




UNUSED 


*• 

7 




UNUSED 


1 




UNUSED 


1 1 


10, FNA 


FIND FILE IN DIRECTORY 


12 




UNUSED 


13 


lO.RNA 


REMOVE FILE FROM DIRECTORY 


1 4 


10, ENA 


ENTER FILE IN DIRECTORY 


1 5 


10, ACR 


ACCESS FILE FOR READ 


1 6 


10, ACW 


ACCESS FILE FOR READ/WRITE 


i If 

1 7 


10, ACE 


ACCESS FILE FOR PEAD/WR ITE/EXTEND 


20 


lO.DAC 


DEACCESS FILE 


21 


I0,RVB 


READ VIRTUAL BLOCK 


22 


lO.WVB 


WRITE VIRTUAL BLOCK 


23 


10. EXT 


EXTEND FILE 


24 


lO.CRE 


CREATE FILE 


25 


10. DEL 


MARK FILE FOR DELETE 


26 


10. RAT 


READ FILE ATTRIBUTES 


27 


10. WAT 


WRITE FILE ATTRIBUTED 


30 




UNUSED 


31 




UNUSED 


32 




UNUSED 


33 




UNUSED 


34 




UNUSED 


35 




UNUSED 


36 




UNUSED 


37 




UNUSED 



Of the function code values Hsted in Table 3.1, only lO.KIL is 
mandatory and has a fixed interpretation, However# if 10, ATT and 
lO.DET are uaed^ they ffuat Have the standard "leaning. If QIO 
directive processing? encounters a function code of 3 or 4 and the code 
is not no-op'ed# it will assume they represent Attach device and 
Detach device# respectively, The other codes are suggested but not 
mandatory. The driver writer is free to establish all other function 
code values on non«»file structured devices. The mask words must 
obviously reflect the proper filtering process. 
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If a driver \b being written for a file structured device, the 
standard function codes of Table 3«-l must be used. 
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5, a, 3 Statui Control Block 

The status control block (8CB) defines the status of a device 
controller. There is one SC8 for each controller is a system. The 
SCB is pointed to bv unit control blocks. To expand on the teletype 
example above» each teletype interfaced via a OLll-A would have a SCB 
since each OUll-A is an independent interface unit. The teletypes 
interfaced via the OHU would also ^ave an SCB since the DHU is a 
single controller but multiplexes many units in parallel. 



S.LHO I DEVICE I/O QUEUE I 



I LISTHEAD I 2 

sIvCT iVECTOR AOOR/a iOEVICE PRIORITY I a 

S.CTM m 

S.ITM IIMT TMEOUT CNTICURNT TMOUT CNT i 6 

S.CON - 

S.STS I CTRLR STATUS ICONTROLUER I 10 



S.CSR I ADDRESS OF CONTROL STATUS REG I 12 



8.PKT iADDRESS OF CURRENT I/O PACKET I \ti 



S.FRK i FORK LINK WORD I 16 

I FORK PC i 20 

i FORK R5 I 22 

I FORK Ra I 2a 



Figure 3»a Status Control Block 



5,a.3.1 SCB Details 

S,LHD (first word equals zeroj second word points to first) 
Description! 

Two words which form the I/O queue listhead. The first word 
points to the first I/O Packet in the queue and the second 
word points to the last I/O Packet in the queue. If the 
queue is empty# the first word is zero and the second word 
points to the first word. 
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Initial iiation/Accessi 

InitlaHfed* not referenced, 
S.PRI (device priority) 
Deac r 1 pt 1 oni 

Contains the priority at which the device Interrupts, 
Initial liatlon/Accessi 

Inltlalliedi not referenced, 
S.VCT (Interrupt vector divided by four) 
Descrlptloni 

Interrupt vector address divided by four, 
Inltlallzatlon/Accessi 

Initialized, not referenced, 
S.CTM (Initialize to zero) 
Descrlptloni 

RSX-UM supports device timeout, which enables a driver to 
limit the time that elapses between the Issuing of an I/O 
operation and its termination. The current timeout count (In 
seconds) Is Initialized by movinq S.ITM (initial timeout 
count) Into S.CTM, The Executive clock service will examine 
active times, decrement them and, if they reach 0, call the 
driver at its device timeout entry point. 

The internal clock count is kept in l«second increments. 
Thus, a time count of I is not precise, since the internal 
clocking mechanism is operating asynchronously with driver 
execution. The only meaningful minimum clock interval is 2 
if the programmer Intends to treat timeout as a consistently 
detectable error condition. Note, if the count Is 0, that no 
timeout will occurf it Is, in fact, an indication that 
timeout Is not operative. The maximum count is 255, The 
driver writer is responsible for setting this field. 
Resetting is at actual timeout or within SFORK, 

Initlalizatlon/Accessi 

not initialized, read/write, 

8,ITM (set to initial timeout count) 
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OescriDt ioni 

Contains the Initial timeout value, 
Initializatl on/Acceasi 

in1tiaHzed# read^onlv. 
8. CON (controller number times 23 
Desc r 1 Pt < on t 

Controller number multipHed bv 2, Used by drivers which are 
written to support more than one controller, S.CON may be 
used by the driver to index into a controller table created 
and maintained internal to the driver itsel*. Indexing the 
controller table enables the driver to service the correct 
controller when a device interrupts. 

Initial ization/Accesst 

initialiied# read-only, 

S.STS (initialize to zero) 

DescriPt ioni 

Establishes the controller as busy/not busy. This byte is 
the interlock mechanism for marking a driver as busy for a 
specific controller, Tested and set bv SGTPKT and reset by 
SIODON, 

Ini t i al i zat i on/Accessi 

initialized^ not referenced, 

SiCSR (Control Status Register address) 

Description! 

Contains the address of the Control Status Register (CSR) for 
the device controller, S.CSR is used by the driver to 
initiate I/O operations and to access* via indexing* other 
registers related to the device that are located in the I/O 
page. This address need not be a CSR| it need only be a 
member of the device's register set. It is accessed at 
system bootstrap time to determine if the interface exists on 
the system hosting the Executive, The Executive uses this to 
set the off*line bit at bootstrap so system software can be 
interchanged between systems without an intervening system 
generation. Otherwise* it is only accessed by the driver 
i tsel f , 
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InU i aH lat i on/Accessi 

< n 1 1 < a 1 < f ed# read/only, 
S,PKT (Reserve one word of storage) 
Description! 

Address of the current I/O Packet estabHsHed bv SGTPKT, 
This field is used to retrieve the I/O Packet address upon 
the completion of an I/O reauest. 

Inltlalliatlon/Accessi 

not Initialised* read-only, 

S,FRK (reserve four words of storage) 

Desc r 1 Pt 1 on I 

The four words starting at S.FRK are used for fork block 
storage If and when the driver deems It necessary to 
establish Itself as a Fork process. Fork block storage 
preserves the state of the driver which Is restored when the 
driver regains control at fork level. This area Is 
automatically used If the driver calls SFORK, 

Inltlallzati on/Accessi 



not Inltlallzedf not referenced. 
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5, 4, a Unit Control Block 

The unit control block (UC8) defines the status of an individual 
device unit end is the control block that is pointed to by the first 
word of an assigned LUN, There is one UCB for each device unit of 
each DCB, The UCB's associated with a particular DCB are contingous 
in memory and are pointed to by the DCB, UCB's are variable length 
between deb's but are of the same length for a specific DCB, To 
finish the teletype example above» each unit on both interfaces would 
have a UCB, 



U,DCB 


I BACK POINTER TO DCB 


i 


U.RED 
U.CTL 
U.STS 
U,ST2 
U.UNIT 


I REDIRECT POINTER TO UCB 


I 2 


iCONTROL FLAGS I UNIT STATUS 


I 4 


I STATUS EXT IPHYSICAL UNIT # 


I 6 


U.CWl 


I CHARACTERISTICS WORD #1 


1 10 


U,CW2 


I CHARACTERISTICS WORD #2 


1 12 


U.CW3 


I CHARACTERISTICS WORD #3 


I 14 


u.cwa 


I CHARACTERISTICS WORD #4 


1 16 


U.SCB 


i POINTER TO SCB 


i 20 


U.ATT 


i TCB OF ATTACHED TASK 


1 22 


U.BUF 


i BUFFER RELOCATION BIAS 


I 24 




i BUFFER ADDRESS 


1 26 


U.CNT 


I BYTE COUNT 


1 30 




I DEVICE 






I DEPENDENT 






• 

■ 
• 






I STORAGE 


I 
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^•^t4, 1 UCB Oetal 1 s 



U.OCB (pointer to associated OCB) 




Desc r i pt 1 on t 



Backpointer to the corresponding DC8, Since the UCB is a kev control 
block in the I/O data structure^ access to other control blocks 
usually occurs via links implanted in the UCB, 

Initial ization/Accesst 

initialiiedi not referenced, 

U.RED (initialized to point to U.OCB of the UCB) 
Desc r i Pt i on i 

Contains a pointer to the UCB to which this device unit has been 
redirected, this field is updated as the result of an MCR Redirect 
command. The redirect chain ends when this word ooints to the UCB 
i tsel f , 

Ini t i al i zat i on/Access t 
Initialized^ not referenced, 
U.CTL (set by driver writer) 
Oescriptiont 

U,CTL and the function mask words in the DCB drive 010 directive 
processing. The driver writer is totally responsible for setting uo 
this bi,t pattern. Any inaccuracy in the bit setting of U.CTL will 
produce erroneous I/O processing. Bit symbols and their meaning are 
as f ol 1 ows I 

UCt ALG • Al ignment bit. 



If this bit s then byte alignment of data buffers is 
allowed. If UC.AuG a then buffers must be word 
al i gned, 

UCATT - Attach/Oetach notification. 

If this bit is seti then the driver will be called when 
an Attach/Oetach I/O function is processed by $GTPKT, 
Typically^ the driver has no need to obtain control for 
Attach/Oetach requests and the Executive performs the 
entire function without any assistance from the driver, 

UCKIL - Unconditional Cancel I/O call bit. 
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If set* the driver Is to be called on a Cancel I/O 

request even if the unit specified is not busy, 

TvDically# the driver is called on Cancel I/O only if an 
I/O operation is in progress. 



UCtQUE " Queue bypass bit. 



If set* the QIO directive processor is to call the driver 
prior to queueinc? the I/O Packet, Once gaining 
to-be«queued control* t he di spos i t i on of the I/O Packet 
is the driver's responsibility. Typically* an I/O Packet 
is queued prior to a call to the driver* which later 
retrieves it by a call to SGTPKT, 

UCPWF • Unconditional call on power failure bit. 

If set* the driver is always to be called when oower is 

restored after a power failure occurs. Typically* the 

driver is called on power restoration only when an I/O 
operation is in progress. 



UCNPR • NPR device bit. 



If set* the device is an NPR device. This bit determines 
the format of the two word address in U,BUF (details 
given under the discussion of U.BUF), 

UCtLGH " Buffer size mask bits (2«bits), 

These two bits are used to check if the byte count 
specified in an I/O request is a legal buffer modulus, 

00 • any buffer modulus valid 

01 ■ must have word alignment modulus 

n - must have double word alignment modulus 
10 - combination invalid, 

UC.AU6 and UC,LGH are independent settings, 

UC.ATT* UC.KIL* UC.QUE* and UC.PWF will usually be zero* 
especially for conventional drivers. 

Every driver must* however* be concerned with its particular 
values for UC,AlG* UC.nPR* and UC,LGH, 

The driver writer is totally responsible for the values in 
these bits* and erroneous values are likely to produce 
unpredictable results. 



t i al i zat i on/Accessi 



initialized* not referenced. 
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U.STS C^nitlfHie to zero) 
OescflDtionj 

This byte contains dev i ce* 1 ndependent status i nf orir^at i on. 
The bit meanings are as foMowst 

US,BSY - If seti dev1ce»un<t Is busy, 

USfMNT • If seti volume is not MOUnted, 

UStFOR • If set# volume is foreign 

US, MOM • If setf device is marked for dismount. 

The unused bits in U,STS are reserved for system use and 
expansion, US, MOM, US,MNT> and US, FOR apply only to 
MOUntable devices. 

Initial ization/Aecesst 

Initialiiedi not referenced, 

U,UNIT (unit number) 

Description! 

This byte contains the physical unit number of the 
device-unit. If the controller for the device supports only 
a single unit^ the unit number is always zero. 

Initial ization/Accessi 

initialized^ read-only, 

U,ST2 (initial ize to zero) 

Detcriptioni 

This byte contains additional dev i ce» i ndeoendent status 
information. The bit meanings are as follows! 

U8,0Ft - If setf the device is offline (that is# not in 
the configuration). 

The remaining bits are reserved for system use and expansion, 

Initializati on/ Access! 

initialized, not referenced. 
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U.CWl (set by driver writer) 
Desc ri pt i on j 

The first of a a-word contiguous cluster of device 
characteristics information, U.CWl and U,C^4 are device 
independent, U,CW2 and U,CW3 are device dependent. The four 
characteristic words are retrieved from the UCB and placed in 
the requester's buffer on issuance of a GLUN* Executive 
directive (Get LUN Information), It is the responsibility of 
the driver writer to supply the contents of these four words 
in the assembly source of the driver data structure, 

U,CW1 is defined as followst 

0««Record"*Ori ented Devi ceC l«yes) 
l*«Carriage Control Devi ce ( layes) 
2«««Terminal Devi ce( l»yes) 
3"-0irectory Devi ce( Isyes) 
4»w81ngle Directory Devi ce( loyes) 
5*«8equent i a 1 Dev i ce ( 1 syes) 
l2««»P8eudo Devi ce( layes) 
l3«»Device Mountable as a 

Communications Channel ( l«yes) 
ia-«Deviee mountable as a FILES-ll 

devi eeClsYes) 
I5»«0evice mountabl e( layes) 

Initialixation/Aecessi 

initialifed, not referenced, 

U,CW2 (initialize to zero) 

Dese r i Pt i on s 

Specific to a given device driver (available for working 
storage or constants), 

Initializati on/Accessi 

initialized! read/write, 

U,CW3 (initialize to zero) 

Deic r i Pt i on f 

Specific to a given device driver (available for working 
storage or constants), 

Initialization/Accesst 



DV,REC 


Bit 


DV,CCL 


Bit 


DV,TTY 


Bit 


DV,DIR 


Bit 


DV,SDI 


Bit 


OV,SQD 


Bit 


DV.PSE 


Bit 


DV,COM 


Bit 


DV.Fll 


Bit 


DV.MNT 


Bit 
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<n1t1aH«ed# read/wpite, 
a (set by driver writer) 
Description! 

Default buffer aize. 
Initial ization/Accesss 

initialiiedi read«»onlvt 
B (SCB pointer) 
DescriPtioni 

THii field contains a pointer to the SCB for tHis UC9, In 
generals on entry to the driver via the driver dispatch 

table will contain the value in this word* since the SCB is 
frequently referenced by service routines, 

Initialifation/Accessi 

initialiiedr read-only, 

TT (initialiie to zero) 

Description! 

If a task has attached itself to a device-unitf this field 
contains its TCB address, 

Initialization/Access! 

initializedf not referenced 

UF (reserve two words of storage) 

Description! 

U.BUF labels two consecutive words which serve as a 
communication region between $6TPKT and the driver. If a non 
, transfer function is indicated, then U,BUF» U,BUF4.2, and 
U.CNT receive the first three parameter words from the I/O 
Packet • 

For transfer operations^ the format of these two words 
depends on the setting of UC.NPR in U,CTL, The driver does 
not format the wordsf all formatting is completed prior to 
the driver receiving control. For unfrapped systems, the 
first word is zero and the second word is the physical 
address of the buffer. For mapped systems, the format is 
determined by the UC.NPR bit which is set for an NPP device 
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L^,CNT (reserve one word of storage) 
Oescriptlont 

Contains the byte count of the buffer described by UtBUF, 
The driver will use this field in constructing the actual 
device request. 

U,BUF and U.CNT are used to keep track of the current data 
item in the buffer for the current transfer (except for nPR 
transfers). Since this field is being altered dynamically, 
the I/O packet way be needed to reissue an I/O operation, 

Initialiiation/Aecessi 

not initialifed# read/write. 
Device Dependent Mordst 

Description! 

The field is variable in length and is established by the 
driver writer to suit driver-specific reouirefnents, 

Initialization/Accessi 



not initialiied, read/write. 



